Things software developers wish they had known in their 20s
Posted on January 27, 2015 • 4 minutes • 712 words
-
The era in which a common career trajectory is to become a lifer at some software company and work one’s way up to higher and higher internal positions has been over for a long time (This era had already been over in the 1990s when I was a young programmer).
-
You don’t owe the company you work for anything beyond what you put your name on when you signed the employee agreement.
-
Don’t stick around too long if the place you are working for isn’t doing much for your bottom line, is not your dream job, and isn’t adding anything new to your resume; that is, the easiest way to get a promotion and a substantial raise is to switch jobs. Don’t switch jobs if you like what you are doing but also don’t stay somewhere only out of loyalty to a company.
-
If you think 2. and 3. are cynical and if looking at things this way makes you feel like an asshole, console yourself with the knowledge that the company you work for views you in exactly the same way and will act on such a view in a second if it is in its interest to do so.
-
You can usually skip all hands meetings even if they are supposedly mandatory.
-
Keep an eye on corporate politics. Being a successful computer programmer is about social engineering as much as it is about software engineering.
-
Make sure you are at the meetings at which the scope and/or requirements are defined for any piece of software for which you are going to be responsible.
-
Don’t go dark. Check in code often – with stubs or whatever if necessary. It is better to check in code sooner rather than later despite the fact that doing so might entail dealing with transitory problems. A few hiccups now are better than a gigantic merge conflict down the line.
-
Be careful about your estimates on dates and on how long things are going to take. Understand that the whole game is about dates. When in doubt just triple what you actually think even if it secretly sounds absurd to you.
-
Don’t be religious about languages, libraries, or platforms.
-
Except for Perl. Perl sucks.
-
At a certain point it is you the programmer who will decide when things are done, even if it isn’t officially supposed to be your decision. Ultimately there is a point before releases when you have to push back at PM or whoever and say, “What you are asking for is not a bug fix – it is a feature request. We are way beyond the point at which we can even be considering introducing new features” It will always be you the programmer who does this because no one else will.
-
Don’t check in a lot of code right before a vacation or long weekend.
-
It is easier to not get assigned to something that you don’t want to work on than it is to get out of it after it has been assigned to you. Trust your instincts regarding death marches. If some project doesn’t feel right, don’t get assigned to it.
-
If you find yourself working for a place at which there is a manager who is printing out burn-down charts and hanging them on the wall, start looking for another job.
-
Working for big companies/name software companies can suck more than you can possibly imagine. Just because your friend who works for Company X is always bragging about the rock climbing wall doesn’t mean that Company X is a great place to work.
-
For all but the simplest cases, prefer recursive descent parsers over regular expressions.
-
Get good at debugging and learn to use a profiler.
-
Focus on making your way into a position in which you are doing what you like software-wise while you are young and can more easily take risks.
-
Don’t break the build. If you do break the build, don’t make a lot of excuses – no one cares – just fix it quickly.
Source: Quora .
In order to get link without Quora censoring stuff, just add any ?abc=
in the url. My personal favorite is ?fuck=you
, in the hope that it will be popular enough to show in their log someday :D