On Being a Junior Developer
mattsencenbaugh.com
mattsencenbaugh.com
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.
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.
I'll also make the (admittedly unprovable) assertion that good code is good writing. Code and sentences can say the same things in different ways - what's the one that minimizes misinterpretation while remaining concise and interesting to read? Just as you want the key points of an essay to live within the most engaging sentences, important code should look important. Style in programming is as crucial as it is subjective, and it requires you to empathize with your readers much as you would when writing anything else.
So yeah, dust off that Tumblr account and use it for something other than reblogging.
How do I avoid becoming a writer, while still being able to have a job as a software developer?
That of course doesn't answer your question. You can probably keep your job whilst having poor communication skills but that will be a (significant) limiting factor for you.
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.
We have locations in SF and Boston.
TDD is both a good practice and a great psychological boost.
Contrary to popular belief, it's entirely possible to create an unmaintainable mess that breaks regularly and is impossible to extend with near-100% test coverage.
As someone said: "There are 2 hard problems in computer science: caching, naming, and off-by-1 errors"
;)
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".
If it's closer to the second, it could signify more of a failure of process than a failure of engineering if engineers are being pushed to release quickly at the expense of planning, time for refactoring, qa, unit tests, etc. That "this should be easy, why's it taking so long??!" attitude can create a toxic environment if it's coming from people who don't understand the issues involved.
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.
They are part of the curriculum in a good SE degree. There is a SWEBOK. http://www.computer.org/portal/web/swebok
Really, it just isn't happening. There is a huge disconnect between best known practices, such as those you linked to, and academia.
Read other code - still very important in admining. Other people write scripts, and there's a wide variety of Perl that's been written. Understand what's good and bad.
2-5 are all true. I just want to reiterate how important it is to ask questions (#4). When you start a junior position, spend time getting to know people. Set up one on one meetings with other people to get to know them and find out what they do. It's important going forward with a cohesive team. From the training side of it, if you're not asking questions I can't be sure that you understand what I'm saying.
Unit testing doesn't really apply to sysadmin that much, but basically have a plan to test if something works as you're going along. If you're making 4 major updates to interdependent systems, how can you tell which of the 4 systems broke the service for the user? I ran into that recently. We had a problem that stumped 4 technical experts and two vendors for over 8 hours, when it was a relatively simple fix (once they figured out what the fix was). Systems get more complex as you add things to them, so be sure to test the individual moving parts.
Refactoring is still always allowed. I feel as though you can extend this to procedures and processes. Where ever you go, there's always some "legacy" that builds up. If you ever receive the answer "That's just the way it's done" you should absolutely look into refactoring that. Odds are the decisions made back then aren't as relevant, because the base assumptions have changed. That's a major area you can show initiative on and start flexing your wings as your own person.
I already knew most of the things described, but it's always nice to refresh your memory:)
In this stage of my career I'm thinking more and more about going somewhere where software engineers get paid what they are worth (And I'm beggining to realize I'm worth something). With "somewhere" I mean another country. Since mine is becoming increasingly unfriendly to live in.
Any suggestions/advice on how to successfully relocate to a job in another country? US or UK come to mind, since there's no language barrier for me there.
For non-commonwealth/non-EU residents, the UK has gotten very difficult since 2008 for people who are unable to get an employer sponsored visa. Even to the point of doing away with both the post-study visa and the Tier 1 general.
UK salaries also can vary drastically depending on where you live (and not necessarily in tune with cost of living differences). We're also on our way out of the economic mess, so salaries are going to be depressed anyway in general as companies hire on, but use the economic mess as a reason to give lower salaries.
Beyond that, I'd say google. There should be a number of forums or immigration sites offering advice for EU residents that would like to work in another EU country. (I'm American, so I consider you lucky in the visa world ;) )
Could also look at the Republic of Ireland?
I've been working remotely for about a year. We have a 10hr difference, talk almost every day, and its been great. It's a small company, only two devs, and we all care a lot about the work we do and the products we release.
So, don't limit your search for jobs where relocation is feasible - look for telecommute/remote jobs as well.
[1] The main barriers to overcome are trust and communication. Both parties need to really trust each other (one will do the work, the other will pay) and they need to have open and honest discussions. At the end of the day the job needs to get done and the fact that there's no direct face to face interaction between the people involved needs not to be an issue.
Any suggestions?
I'm currently interested in C and lower level systems stuff and I've found redis to be a really readable codebase. It's not an introduction to C but provides a good example of how to manage a larger C project.
I also prefer reading through projects I use either as a dependency or as part of a system I'm building.
For that the Apache foundation's projects is an excellent place to start. They have very good documentations and the forums are filled with discussions.
e.g Apache Nutch (before the v2.0 release) - there are many talks and slides you can find on its architecture and the source code isn't hard to read. http://nutch.apache.org/
Twitter's github projects are also very good - especially when I started learning scala.
One project that I read for fun, it was hard to go through but the exercise was worth it is Chromium. http://www.chromium.org/developers
A good developer improves this over time, but it's far too easy to get yourself neck-deep in code and lose focus of what's important.
As a measure, if I find myself getting stuck, what I like to do is go back to the basic level and ask "what is the purpose of this?" This may involve getting more information about the feature/bug, or just talking through different scenarios. I also look at the likelihood of a scenario occurring. Sometimes, you're spending time trying to solve something that nobody knows or cares about.
i would summarize it as: be smart constantly learn find people that are better than you.
but then again, most "seniors" probably never did any of the aforementioned. i met an ex oxford(or cambridge) cs prof who's now doing his own startup a while back.
The main thing that struck me was that how willing he was to accept advice, even though he tought one of the first cs courses in the uk.
It's such an important practice and best to build the right habits from the beginning. The cost of entry is so low with free mocking frameworks. Even commercial vendors like Typemock got into it with their Basic (http://typemock.com/isolator-product-page)
- Making mistakes will kill you, when you sit at home working on your personal projects and a bug slips through, it's not so bad, you can fix them and the client (or yourself) is normally pretty cool with it. On the other hand, when it's someone elses fault, E.G. yourself, your boss will come down hard on you. That's his project, his clients and his shame, if you make mistakes in a commercial environment, it costs someone money - get in to the habit of being your own quality assurance.
- Your wage is shitty. Well, mine is, anyway. You have to learn to deal with this, I could go in to detail about finding housing and the lack of respect you face when you need housing benefits, etc, or can't eat for a few days, but there's no need. Get used to having no money and always put as much as you can aside for that rainy day you think you are immortal from at the moment.
- Get used to being the go to guy for all the boring work, no one wants to sit there and refactor spaghetti code or build yet another custom joomla module when they have some cool CSS3 design or some technical challenge of epic proportions to work on.
- Give your boss respect, he may be friendly but he isn't one of your friends, you can joke with him but at the end of the day don't forget that this (wo)man pays your wages and evaluates your work, if you're making a lot of jokes but you have a week where your work goes wrong, the evaluation will be that you're the class clown.
- Slow down at the start, when everyone goes in to a new job, we work our asses off trying to impress then slow down once we settle in, even more so for a junior in their first role, we want to prove we belong in the industry. The kicker is that this pace is difficult to maintain and once you slow down your boss will notice your apparent lack of progress.
- Always be early, never be late. Your boss doesn't notice the fact that you come in early every day (by 15 minutes), what he does notice is the one day you're ten minutes late and unfortunately the hours aren't interchangeable. If you make a habit of being late, you are going to get fired, this isn't college where you could turn up to a lesson 15 minutes late and get a giggle from your peers for being that guy, this is the real world, where lateness isn't tolerated for very long.
- Arrogance is bad. You aren't arrogant, but you have an opinion and you come across as it, starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client. Your boss wants to appear to be an all singing, all dancing super coder and until you have a few more years under your belt, your opinion is largely invalid. However, if something is seriously wrong, drop your boss an email or a skype or a campfire (That's a thing, right?) and explain why in the least condescending way possible, if you do this tactically and only at the right times it will look very good on you.
If anyone is about to jump in to their first job as a junior or needs any advice, feel free to email me, I normally check it every couple of hours.
> Making mistakes will kill you
Nah they won't. No matter how it's worded, your current agreement with your employer is actually something like: "We agree that you will make mistakes and learn on the job. In return for this we will pay you peanuts". If they wanted a senior developer, they should be paying for one.
It's also important to point out that the mistakes you make now will play a big part in making you a senior developer. If you're putting yourself out of your comfort zone often enough you should be make plenty of mistakes on a weekly basis. It's nice if like you say, you catch them before your boss/clients do, but I wouldn't beat yourself up too much if you don't.
> Your wage is shitty.... or can't eat for a few days
Leave. Even with only six months of experience you're probably worth at least double what you're getting paid now. That a developer can't eat, in this market, is truly fucking ridiculous.
> Get used to being the go to guy for all the boring work, no one wants to sit there and refactor spaghetti code or build yet another custom joomla module
Refactoring spaghetti code doesn't go away when you become a senior developer, and it's a massively important skill to build up. Most non-trivial projects on big systems will require that you do this. I know it doesn't feel like you're learning anything, but reading code is a hugely important task that junior developers need to do more of (as opposed to just writing it).
The more you do this, the better you will get at understanding big systems quickly. Learn this now, do it at future clients 1, 2, 3, and 4. By the time you do it at client 5, you'll be so good at it that they'll think you're some sort of prodigy (so get paid accordingly!).
> Slow down at the start,... your boss will notice your apparent lack of progress
Who cares? If your boss has a problem with your progress he should let you know and you should work together to improve it. Also: Leave!
> Always be early, never be late. Your boss blah blah...
Personally I like coming in at the crack of dawn and leaving very early. I know other wickedly good developers who prefer turning up at 11 and leaving at 8. Non-developers don't get this, but it's fine. As long as you're delivering results and are available for any in-person rituals, no one should really care what time you arrive/leave.
> Arrogance is bad.
You say that now, wait a few years. When you've surpassed your heros in terms of skill/knowledge and spend most of your time watching other developers wrap themselves into webs of complexity for no good reason (and then have to clean up after them), then tell me not to be arrogant. A strongly worded opinion, arrogant or not, has demonstrably saved months of work and oodles of money for clients down the line.
> starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client
Bzzzt, wrong again! Expressing my opinion in front of clients, even as a junior developer, has consistently been a positive experience for everyone involved, including my boss's at the time. "No, that's wrong" is admittedly a little strong, but it really depends on the content. "No, that's wrong, the google search algorithm works like X so you'll probably have better results doing activity Y" or "No, that's wrong, if instead we make it a RESTful API we get the following 3 benefits..." is a hell of a lot more useful to everyone in the room than you just sitting in a corner being demure.
> Your boss wants to appear to be an all singing, all dancing super coder
I don't think I like your boss very much.
Based on the attitude you've displayed in this post, by any metric you're probably better than you think you are. The worst sort of junior developer is one with no humility, but I think you can afford to be a little more confident, especially when dealing with "Your boss". Also, Leave.
Practice voicing your opinion and arguing for it in a way that isn't confrontational. 9 out of 10 times, it's as simple as acknowledging the other person: "I see where you're going with this, it's a good way to solve A, B and C. But when we get to D, I fear X will bite us in the tail - Y can avoid that.". This also avoids the stinging embarrassment of being arrogant and later being proven wrong.
In practice, I word things similar to what you've described here, probably even more deferent.
Still, if I believe it is in a clients best interest to do Y, I don't mind sticking my neck out and make the case more strongly for it, even if I turn out to be wrong.
Additionally, I've found over my career that I've learned the most useful skills, both technical and otherwise, from developers who were fantastically arrogant. They also happened to deliver the most value to the business, so no one cared.
We all make mistakes, big ones, small ones, ones people notice and ones they don't. If we didn't make mistakes we wouldn't need testing.
What we do, is we learn where the mistakes are most likely to occur and we learn to mitigate the effects of those mistakes.
The problem is that at the time I took my job, I didn't have much choice, I was in a shitty position, no job, no money, no home, etc. and I took the fist position which came along.
I wish I had been in a better position and been able to better evaluate my current workplace, but in my bosses defence, I am the first (out of family) employee for this oompany, my boss is new to the world of being a boss too and he is unsure of when and where to show his authority.
As for moving elsewhere, I am currently in the process of applying for other jobs and hoping one of them come through.
I should state that I actually like my boss, he's a good person and is as new to being an employer as I am to being a commercial programmer.
I would like a more professional and tactful environment in my next position but I don't in any way blame my boss for how I feel, in fact I have a lot of respect for him.
No shame in that. I graduated in 2001, and was ecstatic to receive my first (and only) job offer. 1.5 years later, the company went bankrupt, and my team of ~7 was sold (OK, the IP was sold, the team got offers). News came out that one person on the team was getting a raise during the transition and that person was me!!
...because the new company didn't have a pay grade that went low enough to accommodate my existing salary. :/
About 5 years later I cracked 6 figures in the Midwest U.S. and I'm not a super/rock/ninja/adjective du jour star by any stretch. My $.02: Keep working hard, know what you want (and don't be afraid to ask), communicate well, and generally be a Good Guy/Gal™. The rest kind of fell into place for me and my guess is that it will for you too. Best of luck!
And this is from a reasonably sized company (~1500 full time staff)
We do a lot to mitigate mistakes (code reviews, testing, rigorous QA), but when they happen I'm not getting the switch.
We're taken care of w.r.t wages and time. Hours are totally interchangeable here--if I arrive 45 minutes late, I make it up on the back end. I'm also taking care of a graduate degree out-of-pocket (speaks to both the wage and time thing).
I won't speak to arrogance (fallen into this trap, and you don't want to be the guy asserting falsehoods matter-of-factly), but junior devs shouldn't be afraid of assertiveness. I wasn't happy about something here, and when I was asked to discuss it with our tech management team they (a) listened and (b) acted on it immediately. That's big.
- Making mistakes will kill you, when you sit at home working on your personal projects and a bug slips through, it's not so bad, you can fix them and the client (or yourself) is normally pretty cool with it. On the other hand, when it's someone elses fault, E.G. yourself, your boss will come down hard on you. That's his project, his clients and his shame, if you make mistakes in a commercial environment, it costs someone money - get in to the habit of being your own quality assurance.
- Your wage is shitty. Well, mine is, anyway. You have to learn to deal with this, I could go in to detail about finding housing and the lack of respect you face when you need housing benefits, etc, or can't eat for a few days, but there's no need. Get used to having no money and always put as much as you can aside for that rainy day you think you are immortal from at the moment.
- Give your boss respect, he may be friendly but he isn't one of your friends, you can joke with him but at the end of the day don't forget that this (wo)man pays your wages and evaluates your work, if you're making a lot of jokes but you have a week where your work goes wrong, the evaluation will be that you're the class clown.
- Always be early, never be late. Your boss doesn't notice the fact that you come in early every day (by 15 minutes), what he does notice is the one day you're ten minutes late and unfortunately the hours aren't interchangeable. If you make a habit of being late, you are going to get fired, this isn't college where you could turn up to a lesson 15 minutes late and get a giggle from your peers for being that guy, this is the real world, where lateness isn't tolerated for very long.
- Arrogance is bad. You aren't arrogant, but you have an opinion and you come across as it, starting sentences with "actually, I think" or "No, that's wrong..." will land you in the shit, especially in front of a client. Your boss wants to appear to be an all singing, all dancing super coder and until you have a few more years under your belt, your opinion is largely invalid. However, if something is seriously wrong, drop your boss an email or a skype or a campfire (That's a thing, right?) and explain why in the least condescending way possible, if you do this tactically and only at the right times it will look very good on you.
Have you thought about moving to London?
That aside, I agree with a lot of what you've said, I'm currently feeling pretty shitty about my job and actively seeking work elsewhere (and being interviewed, etc).
Out of curiosity, why do you propose a relocation to London?
Not sure about the OP, but the London market has been screaming for web developers for the past three years at least and I would be very surprised if it slowed down any time soon.
To give you concrete numbers, I came off a contract at the end of October (I'm taking a few months off for baby arrival, due any day now) and went to one local user group event to line up some new work for January.
Based on that outing and pinging a couple of recruiters, I have two potential clients who have given me offers for 3+ month contracts, another two interviews next week and the client I just finished with wants to re-contract too. None of the new clients are referrals. Daily rates (subject to change!) circa £500.
I get regular emails from past employers asking for recommendations for full-time developers too. In the vast majority of cases, I have no one to recommend as all of the good full-timers I've been in the foxhole with tend to be quite happily employed.
Move to London together, perhaps? You can probably make more alone there, than your two wages together at the moment. (Add in a London job for her, and it becomes even better.)
But understand that while you might be able to become great, you're in Lancashire. There aren't going to be as many big deals going on there.
A developer in London can make it big.
> Making mistakes will kill you
Your place of work is terrible. When there's a bug in my code, it's because I made a mistake, but it's also because A) my code reviewers didn't catch it, and B) the testers didn't catch it. In a decent organization, blame should be spread and the reaction to problems should be systemic.
> Your wage is shitty
Your place of work is terrible. I had more money than I knew what to do with starting out.
> Get used to being the go-to guy for all the boring work
This is somewhat true, but starting out, many things are new to you, so even if they'd suck for a more experienced dev, it's still good stuff build a foundation on.
> Give your boss respect, he may be friendly but he isn't one of your friends, you can joke with him but at the end of the day don't forget that this (wo)man pays your wages and evaluates your work
I've considered lots of my bosses my friends. Give your boss respect if they earn it. If they don't, complain to someone you DO respect or leave. Also: I've had several reviews mention my sense of humor as a positive.
> Slow down at the start
Don't try to impress anybody. Just do your best because why would you do anything else? And if you're slowing down, it's because they're giving you boring work. Talk to your boss or go find better work.
> Always be early, never be late
Your place of work is terrible. They don't trust you. (My hypothesis: they're projecting their own poor work ethic onto you.) I can work 7am-4pm, or 8-5, or 9-6, or whatever. I can come in late whenever and nobody bats an eye, because I am trusted.
> Arrogance is bad.
Sure, of course, so just mind how you speak. Be good-natured and generous in your assessment of others.
> Your boss wants to appear to be an all singing, all dancing super coder and until you have a few more years under your belt, your opinion is largely invalid.
Your place of work is terrible. Nobody should expect you to be a genius, and your opinion does matter. If they respected you, they'd ask your opinion, and constructively criticize your ideas so that you improve.
In case I forgot to mention it: your place of work is terrible. It is not like this everywhere. Don't start feeling trapped, though: feel empowered. You deserve better.
This does not sound like a positive work environment! This seems to be very unusual.
Also, if you can't make enough to live on, that's insanely unusual in the West.
You need to be able to fail and make mistakes. That's part of being a junior developer. You need to be able to provide intelligent opinions, even contradicting your boss.
But you're right about being aware of the politics and what your boss wants. It's usually bad form to cause one's boss to lose face in front of clients/his peers/bosses.