Some advice for junior developers new on the job
First of all, the below applies to a quite high stakes setting in a financially related company, a place were we don’t move fast and break things if we want to continue being in business. A bit different from the early days of Facebook in other words, back in 2007 I couldn’t care less if the like button was temporarily out of order or not, in fact I still don’t. And if I had to guess I would say that they’ve probably never moved fast and broken things in the ads department where all the clicks are tracked, ads displayed, advertisers billed etc.
It wasn’t always like this here but lately the transaction volume has increased to such an extent that even a small error can result in thousands of euros in damage within minutes.
Fast but sloppy
With the above in mind the worst thing you can do is give the impression that you are a loose cannon, or even a suspicion. Here are a few ways you do that:
– Push commits that were obviously not tested a iota because they break things in obvious ways. You might do that because you think that they are so small and trivial no testing is needed, you’d be surprised how many times I’ve thought the same. But that kind of thinking wears off after a few years, dispensing with it immediately will set you on the fast track to that senior role.
– Push commits that were only cursorily tested for QA to test. QA is not your bug squasher, it’s the final instance that will try and find issues with your code when your own efforts have been exhausted.
– Fighting a framework because you want to move so fast that you don’t feel like you have time to learn the way things are supposed to be done in that framework. One purpose of frameworks is to force newbies like you to work in a certain preferred way, breaking out sets off alarm bells, just like breaking out of jail, and it is not a good thing.
– Starting major work on an unfamiliar code base too soon. There are only two scenarios here, either you’re a massive genius and all will end well or you didn’t spend enough time familiarizing yourself with the code in order to understand it more thoroughly before you started modifying it. Chances are it’s the latter and it makes you look reckless.
The economics of productivity
It’s common in dev departments to promote technically competent people to management roles, and it is common for those people to accept these new roles. They pay better and they’re viewed as career progression. That doesn’t mean that they like to manage, probably the opposite in fact. Leading yes, managing no. Leading is directing work, assigning projects and tasks, making architectural decisions etc. Managing connotes having to prevent some kind of unwanted behavior, an unpleasant an frankly unnecessary task if the recruiting hasn’t failed. That’s why you will probably piss off your manager immensely if he has to prevent you from for instance being fast but sloppy.
Irregardless of whether it’s your manager or some other senior dev in charge of onboarding you, chances are that they’re at least an order of magnitude more productive than you. Not because their IQ is ten times higher but because they’re much more familiar with the code base, how various APIs interact, various quirks relating to third party APIs etc, in addition to statistically having a somewhat higher IQ (survivorship bias).
This leads to an interesting observation, if you have to ask them for help on something that it would’ve taken you an hour to figure out on your own and they will have to spend more than roughly five minutes to explain it to you then the company loses out.
And so you progress, either slowly or more quickly because you get help, but in pure economical terms it’s not necessarily better for the company to help you get up to speed in the fastest possible time period. Especially if you’re a fast learner which is quite ironic.
But if these dividends do not materialize, ie you don’t seem to progress, then you will most probably get fired if you can’t be assigned less intellectually demanding tasks. This inflexibility will make you smell like someone who will have to be managed which we’ve already established is a bad thing. So even if you don’t get fired right away you will have no career progression and no raises and eventually some excuse will be made up to fire you if you don’t quit by yourself.
With the above in mind, some pointers:
– Don’t ask for help if it will take you a fairly short time to figure it our yourself, by the time the senior dev has gotten up from his chair he could’ve ended up wasting more junior dev equivalent minutes than you would’ve wasted figuring out the problem yourself.
– Give a problem a certain amount of time before you ask for help so you don’t prematurely ask for it and thus waste money.
– Don’t ask for help in decision making if the options to be decided between are too similar or irrelevant in the grand scheme of things.
– Try to batch the support asking, save a up a few issues and / or problems and then go through them all at the same time, this pointer is much more important than it might seem, it makes a huge difference (saves a lot of context switching for the senior dev).
– On the other hand, being afraid to ask for help so you spend 6 hours on a problem a senior dev could’ve explained to you in 5 minutes is also not a good thing.
General behavior and culture
Try to adapt to the culture you’ve been hired into, you could try and change it if you don’t like it but it’s probably a wasted effort and you will have to decide whether to move on or suffer it.
Regardless of culture, it’s a good idea to conduct yourself properly, check out how your older peers behave and try to emulate. Chances are they behave much less impulsively and with more integrity.
Some practical advice:
– Don’t be a wise-ass, if you’re right (which is the best case scenario) you come off as just that, a wise-ass. However, if you’re wrong you’ll come off as a complete idiot. So being a wise-ass can’t possibly be to your advantage in any way or situation.
– Similarly to the above point, don’t make bold statements if you’re not 100% sure and probably not even then because it’s a fallacy of youth to feel 100% confident in something due to a lack of experience and knowledge.
– Use proper language, if the f-word is used sparingly where you work then you use it sparingly too. Phrase things in soft terms, use “I feel like we should refactor this piece of code due to the fact that … ” instead of “this piece of shit code is horrible and we have to rewrite it”. Just like with the wise-ass advice you stand nothing to gain from expressing yourself like in the latter example.
– Face up to your mistakes, tell it like it is instead of trying some lame excuses, or worse, trying to blame someone who had nothing to do with it.
Some final words
A short summary, behavioral issues can be course corrected but if your intelligence is so subpar that you need micromanagement (read somebody doing your job for you) or you’re fast but sloppy you’re probably in the wrong line of work or at the wrong type of company at least.
Theoretically the fast but sloppy behavior should not be too hard to fix but in practice it has proven to be very hard in my experience.