
On Being a Junior Developer - msencenb
http://mattsencenbaugh.com/on-being-a-junior-developer/
======
nhashem
One 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.

~~~
tomjen3
And I who entered this business because I liked to deal with computers, rather
than humans.

How do I avoid becoming a writer, while still being able to have a job as a
software developer?

~~~
schmrz
Most of us like handling computers more than humans but it's not really that
black and white. In order to get the most out of your career you will need to
learn how to handle humans too.

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.

~~~
tomjen3
Oh I should have been much more accurate. I hate having to be a communicator,
I don't mind handling people -- they are (in aggregate) a pretty interesting
bunch and I love to figure out what makes them tick.

------
larsberg
The 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.

~~~
marblar
Can I ask what those issues are?

~~~
larsberg
Sure, drop me mail. I'd prefer not to chat about it on a public forum. People
(myself included) get defensive about their alma mater, but in e-mail you can
just ignore me if you think my gross generalizations from experience are off-
base for you :-)

------
danso
I really, really wish TDD, or any concept of unit testing had been taught in
my courses. Nothing has improved my ability to understand decoupling,
orthogonality, and the importance of naming conventions than test writing. And
on days when I can't muster the energy to write heavy code, I can at least
write the tests that I know I'll need to pass...and the next day, that heavy
code task is practically done.

TDD is both a good practice and a great psychological boost.

~~~
alinajaf
They taught me unit testing at university and I've been using it ever since.
It has a lot of benefits. But things like decoupling, orthogonality and naming
conventions are worth thinking hard about in their own right, not just in
terms of the side effects of TDD.

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.

------
civilian
There are two (4) steps.

As someone said: "There are 2 hard problems in computer science: caching,
naming, and off-by-1 errors"

;)

------
speakingofprog-
This 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.

~~~
danenania
It's hard to say without all the details. It's also the kind of thing that can
be hard to gauge from outside the project. It could be new developers making
rookie mistakes. It could be simple incompetence. Or it could be that what
sounds simple to you on the surface balloons in complexity after being forced
to fully engage with the problem and all its edge cases.

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.

------
ericHosick
I 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.

~~~
tjpick
No.

They _are_ part of the curriculum in a good SE degree. There _is_ a SWEBOK.
<http://www.computer.org/portal/web/swebok>

~~~
ericHosick
I found, based on my few years of experience lecturing in IT and BIS at a
large university (72,000 students), was that very little emphasis was placed
on building up IT as a profession based on a body of knowledge.

Really, it just isn't happening. There is a huge disconnect between best known
practices, such as those you linked to, and academia.

------
Tashtego
I would add "practice what you preach" to this. Everyone hates the junior
developer who says "ugh, this code sucks, it doesn't even have tests."
Everyone loves the junior developer who says "ugh, that code didn't even have
tests, so I found a seam and added some tests for the new method I added,
here's how to run them."

------
caw
I am what I guess you'd consider a junior sysadmin. I graduated in May of
2011. While it's not being a developer, all of the points stand.

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.

------
Zanyinj
I'm also a 'Junior Developer'(around 2yr) and am currently in the phase where
I have started to see the faults in the systems my seniors design. There's a
module that's driving me nuts, and I'm still pondering on how to tell the
senior developer(who wrote it) that it's crap, over engineered and too
specific. The module works to an extent, but I can see problems up ahead if
the module doesn't get fixed or an alternative is created.

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.

~~~
thisone
This all depends on where you're from. US is easier for Canadians, UK easier
for Australians, for example.

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.

~~~
Zanyinj
I'm from Slovenia, EU resident.

~~~
thisone
Then the UK should be relatively easier for you, since you should be able to
apply for the same jobs as a UK citizen, I think?

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?

------
xiaoma
On tip #1, how _big_ does the chunk of other people's code need to be to teach
you about the things he's talking about? I've really enjoyed reading
algorithms but struggled when looking at source code for large projects on
github. I often feel lost and don't really know how to dig in.

Any suggestions?

~~~
3minus1
I feel the same. I always hear people say to read others code. Really? Like
what?

~~~
alinajaf
It depends what you're interested in learning about. I'm a ruby/rails
developer by trade so rails is a really good place to start for me. The open
source libraries around it like devise, cancan, haml+sass etc are required
reading if you're going to be using them regularly.

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.

------
scott_w
Something I learned early on was the importance of stepping back and looking
at the bigger picture.

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.

------
cllns
Good 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.

~~~
msencenb
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.

------
rjzzleep
am i the only one who finds the article only marginally related to "being a
junior/senior/antique developer"?

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.

------
unitesting24
Love #6 & #7 - Unit Testing and Refactor.

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>)

------
shanelja
I'm currently a junior developer and will share the lessons of my experience 6
months in:

\- 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.

~~~
alinajaf
I'm currently a, "something" developer this is what I would tell you over a
beer after a hard days work in the salty salt mines of programming, after 6+
years on the job.

> 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.

~~~
shanelja
Thanks for your advice and information - personally, I agree with a lot of the
points you've made.

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_.

~~~
Hannan
>> 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.

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!

------
cpeterso
I recommend contributing to open source projects, particularly well-known
ones. It is a good way to see how other people and projects work, expand your
resume experience, and network with people in other companies.

~~~
linpythio
That's a good idea.Open source project is good practice for
programmer,especially junior.Because you can read and modify others' high
quality codes.

~~~
cpeterso
For people looking for a project, Mozilla has a lot of documentation and tools
to help first-time contributors. "Contributing to the Mozilla Codebase" [1]
documents how to get the code and build your own Firefox. "Bugs Ahoy" [2] is a
Bugzilla search engine that filters "good first bugs" based on programming
language and interests.

[1] <https://developer.mozilla.org/en-US/docs/Introduction>

[2] <http://www.joshmatthews.net/bugsahoy/>

------
j_baker
My advice: don't pay _too_ much attention to what more senior developers tell
you. senior != more_talented

~~~
novamantis
This will slow you down incredibly. Instead of ignoring your seniors/peers,
QUESTION their "authoritative" commands. You will learn much, MUCH more that
way. It also might put them in their place if they are massive egoists. Never
feed the ego.

~~~
j_baker
I would like to point out that I never suggested that one should _ignore_
their seniors and especially not their peers. I merely suggested that
seniority only buys a person so much respect. It's important not to exceed
that quota.

------
rburhum
Matt was the smartest freelancer I ever hired

------
hawleyal
Pfft. _On being a developer_ FTFY

