Coding as an employee

You are / about to be, an employee of this software company and coding is part of your job. Now, how would it feel like? What sort of stuff would your employer expect? What stuff would you expect?

The right question to ask is this: What is the quality of code you can deliver and how complex are the problems you can solve? Most of the problems out there that needs paid employees to keep the business running can be broadly classified as follows.

Case 1 – New product in the market space; does not have much end users; small independent self contained team:

  • This is the fun part in your career you would ever find.
  • You get to write a lot of code, implement features day in and day out.
  • You can take some liberty and refactor code the way you see fit
  • See how the company manages to expand its business and how the product evolves
  • Free knowledge all around the company which would come in handy if you start your own company someday

But,

  • Be prepared, the feature that you worked hard on might go to trash very soon. The product would evolve so rapidly that you might have to scrap your code way too often before it reaches the end user.
  • The work might get so interesting that you would forget to balance it with your life

Case 2 – A fairly proven product; already has too many components working together solving a variety of problems; user base is increasing rapidly than the product can handle; the company has found some huge investment and are trying make the product go wild:

  • You get to read and analyse a lot of code, and write few lines here and there.
  • Writing clean code is mandatory. In some cases if you are lucky, you get to refactor the old ‘bad’ codes and leave things cleaner than it was earlier.

Case 3 – Coding for an enterprise:

  • You get free knowledge from the seasoned seniors,  you can get to know how their career has shaped up.
  • You have this product which makes a lot of money and has a lot of users.
  • You get to read huge code base and write very little. Sometimes, even if you see bad code, you are not supposed to change it as it would be too ‘costly’ for the company to change code unless and until it is really needed. (Chances are, the company never took risks in migrating to newer, cooler technology stacks; never tried Haskell. Haskellers never have to be afraid of refactoring code!)

Irrespective of what you are, when you code as an employee, the following points helps in finding that inner peace:

  • Always keep a look out, explore the latest developments in the tools you use, and explore new areas.
  • Keep experimenting with what you have learned. Even if the company does not need it, make it for your satisfaction and give it out for free.
  • Keep the business owner mindset alive!
Advertisements