On Being a Junior Developer
mattsencenbaugh.com
On Being a Junior Developer
1–10 of 73 posts
Re: On Being a Junior Developer
#2Good read! Seems like good advice.
It makes sense that graduates from elite schools would be afraid of trying new things, since they're used to success and never had to deal with failure. I never thought of that.
Re: On Being a Junior Developer
#3One other major suggestion I'd add:
Practice writing. Just write whenever you can, in whatever environment, no matter how unformal. Your company wiki, your personal blog, whatever.
Maturing from a "junior" engineer into a more experienced one usually means initiating suggestions, not just following them. As the OP said -- have an opinion! But your suggestions will always be limited to how well you can communicate them. And a lot of your interactions wherever you work will be with non-technical people, so the better you can frame technical situations to them, the more they will enjoy working with you and cede to your judgment.
I've seen so many talented software engineers not find the professional success they deserve because they couldn't write. You will do brilliant things, and those brilliant things will make your employer money, and your ability to write will matter a lot in how much that brilliance is valued. Likewise you will make mistakes, and sometimes those mistakes will cost your employer money, and when that happens someone will be upset, and your ability to write will matter a lot in how soon they calm down.
Some of the most important keystrokes in my career were not for writing lines of code, but for how I composed an email. I'm not saying your expertise in software development doesn't matter -- of course it does, and a bad software engineer that's a good writer does not make them a good software engineer. But your ability to write and communicate can be a tremendous force multiplier for your career.
Re: On Being a Junior Developer
#4Good read! Seems like good advice. It makes sense that graduates from elite schools would be afraid of trying new things, since they're used to success and never had to deal with failure. I never thought of that.
Thanks! I think this problem is in a lot of junior devs as well (not just elite college grads). You get good at one thing and feel comfortable within that bubble, but the real growth comes from pushing yourself out of that comfort zone.
Re: On Being a Junior Developer
#5This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built and deployed about 4 months ago, it was a week of one developers time start to finish. Ever since deployment there has been bug after bug after bug, every time they fix one bug they break something else. This is an extremely simple system that should (in my experience as a developer) not have any problems. Does this sound normal, for every deployment to have new system breaking bugs? Does this sound something like they're letting junior developers (in skill) deal with systems beyond their scope of understanding? or is it normal for systems to be breaking frequently? This is the only company I have worked for with engineering that affected my work so I'm not sure if this is unique to this company or is common place in the corporate world.
Re: On Being a Junior Developer
#6I would fault some of the points listed, like "Embrace Unit Testing", to a failure of Software Engineering as a discipline.
Mechanical Engineering, Electrical Engineering, Physics, Doctors, etc. all have bodies of knowledge.
We, as an industry and discipline, have no real body of knowledge. Do Doctors have the ability to make up procedure on the operating table?
Why is it, then, that we don't have standard practices, like unit testing, and help get these pushed into the educational system? Should students even be learning how to write code without unit tests? Without a backlog (if that is what industry agrees to)? Without an understanding of systems? And so on.
Re: On Being a Junior Developer
#7One other major suggestion I'd add: Practice writing. Just write whenever you can, in whatever environment, no matter how unformal. Your company wiki, your personal blog, whatever. Maturing from a "junior" engineer into a more experienced one usually means initiating suggestions, not just following them. As the OP said -- have an opinion! But your suggestions will always be limited to how well you can communicate the…
I could not agree with you more.
I would also add that it's not just writing those emails or communicating but actually taking the time to understand the office politics/social dynamics of the place you are working.
I've seen many talented engineers miss out on the success they deserve because they felt that their specialty being "technical" meant they didn't have to concern themselves with "the politics". Often it's partly true, and it's very tempting to those more introverted than average.
Write well first, but after that they should learn to tell exactly who to write to, what tone to take and when they should write to them. It can make a truly astounding difference in your career path.
Re: On Being a Junior Developer
#8There are two (4) steps.
As someone said: "There are 2 hard problems in computer science: caching, naming, and off-by-1 errors"
;)
Re: On Being a Junior Developer
#9This is only tangentially related: I work a relatively big startup and I'm not not in the technical side of the company. A piece of "simple"* software was built and deployed about 4 months ago, it was a week of one developers time start to finish. Ever since deployment there has been bug after bug after bug, every time they fix one bug they break something else. This is an extremely simple system that should (in my e…
I've worked at companies where this seems to happen often and it usually comes down to two things:
1) Poor communication and/or planning as far as what the end result was supposed to be. The developer built it the way they thought it was supposed to work, they find out later that it's incorrect or the specifications for it keep changing making the developer add one hack after another to get it to do what it needs to do. They'd probably like to just rewrite the whole thing, but by now it's too late.
Jr vs Sr: Sr can see this coming and does whatever he/she can do to minimize it. Doesn't necessarily mean they can stop it from though, it might be too high up the chain of command.
2) Little to no testing. The developer built it and said "done" and then it was passed on to the end user. Anything of any complexity is going to be riddled with bugs if there isn't some kind of QA process in between. Developers typically suck and QAing their own work.
Jr vs Sr: Sr has more experience to see possible problems before they become problems and if no QA procedure exists, will at least try to run it by a colleague before claiming it "done".
Re: On Being a Junior Developer
#10The biggest one I'd recommend is "find a mentor." And I don't mean a manager (unless you're going on that path), but rather a technical leader that you can meet with once a week to month whose opinion you value and can provide you honest feedback on your work.
You should plan to drive these meetings; count on them only to show up, drink coffee, and answer your questions. If it is not your most valuable hour of the week/month, you either have the wrong mentor or are handling it wrong.
And if your company does not have such a mentor, you should either look to find one that does or make sure you're getting paid well.
Author can also follow up with me via e-mail if they want Stanford-specific advice. There are a specific set of things that the perfect-A average and BS+MS degree in CS in 5 years crowd runs into during their first few years out of school that I'd be happy to share. It's true of every school, but we had a lot of experience with the A students from Stanford, Yale, MIT, Princeton, etc., and they all seemed to run into the same problems as their alumni forerunners.