

Letters to Junior Developers - smithderekm
http://www.codeovereasy.com/2015/01/letters-to-junior-developers/

======
gharial
Nice writeup, with the exception that you should never, ever "love something
so much you'd do it for free" in a professional setting. I get that the
intention behind the statement isn't literal, but that kind of attitude is
what makes hiring managers think that they can make junior developers sub-25k
offers in places like Manhattan.

I had the confidence to never allow myself to be low balled and quite enjoyed
the lectures about "paying my dues" and "being thankful to have an offer in
this field/economy" \- the looks on their faces when I still rejected the
offer doubly so. But not every hopeful developer has that.

~~~
vonmoltke
In addition, it pushes company culture to use passion as a hiring signal,
discriminating against developers who do not show sufficient levels because
they are not "good". In my opinion, this leads to both the so-called "talent
shortage" we have now and the underrepresentation of certain groups in the
industry.

There are far more developer jobs than there are "passionate" developers. Many
developer jobs that need doing are partially or totally a slog that no one
would be expected to love.

~~~
gharial
This is definitely true. I've been labeled on occasion as "not passionate" for
not being willing to work myself into the ground at 60+ hours a week with a
four hour round trip commute.

That's not to say that I won't work long hours at crunch time or I have a
problem with going the extra mile. But if your "crunch time" is 52 weeks a
year, it's no longer a matter of passion, it's just exploitative.

~~~
3beard
Young programmers can easily be guilted into working 60 hours a week because
young smart people tend to be a little naive about how the world turns. My
advice to junior programmers is "your recruiters/managers are probably more
cynical than you think, understand you better than you think, and manipulate
you better than you think".

~~~
vonmoltke
Ah yes, passionate and naive is an awesome combination for exploitation.

------
onion2k
I really don't agree with the final "Present a solution, not just a problem"
point. Quite often a developer will be able to see a problem but won't have a
clue what the solution is. Having a "Present a solution, not just a problem"
approach means that developers won't want to inform you that the problem is
there, and then it'll surprise you later at the worst possible time. If you
have a solution, great. If you don't, also great. But _always_ communicate a
problem exists.

~~~
yaddayadda
I'd modify it to "Don't present just a problem, present a solution, _or all
the solutions you 've tried and why they didn't solve the problem_."

I've also heard some companies have time limits on seeking help, e.g. if
you're a junior developer and can't solve the problem on your own within 15
minutes, ask for help.

~~~
datashovel
I encourage the 15 minute rule, but not to just ask help from anyone. Another
difficult thing to accomplish as a manager is to prevent unnecessary
interruptions for anyone on my team. In an ideal scenario all that stuff goes
through me. Not because I want that control. It's because I have the
responsibility. One of those responsibilities is to get the most out of my
team. So if that means interrupt me instead of your teammates that's my
preference pretty much 100% of the time, unless I'm unavailable.

------
nawitus
"Some organizations pretend that they are about other things, like serving
people or changing the world. But in truth they are measured by money."

And in practice they rarely are not. Nobody calculates the total cost of an
unnecessary two hour meeting where 8 highly-paid employees discuss about
something almost completely irrelevant.

Another problem with this is that it's extremely difficult to calculate
anything when it comes to software, so expenses and profits are usually
created using Stetson-Harrison when some higher-up needs a budget.

In fact, I'd say that companies that don't have such an "accounting" focus on
software development do a lot better.

~~~
vkjv
"And in practice they rarely are not. Nobody calculates the total cost of an
unnecessary two hour meeting where 8 highly-paid employees discuss about
something almost completely irrelevant."

In my experience, that is absolutely not true. Just about any meeting I've
ever been in with more than 6 people, the very first question was, "this
meeting is expensive, does it need to happen and do we need everyone?"

~~~
k__
In my experience, it is absolutely true.

And I worked at really small and really big companies.

No one thought about the cost of a meeting, they thought of them as a normal
thing every company does for a few hours a week.

------
djb_hackernews
This is going to come off extremely cynical but this post intersects at 2
points that interest me. One being advice I would give to my former self, and
the other is how I as a person fit into the business world.

The post makes a simple yet important observation:

> That business is measured by a very simple equation: revenues minus expenses
> equals profit.

For those of you starting out it may not be obvious to you that there are VERY
well paid people whose sole job it is is to look at the expenses column and
figure out ways to shrink it. With that in mind you should understand that if
you work at a technology company YOU and your fellow developers are the
biggest expense. Plan accordingly.

~~~
AtmaScout
The developers at a software company are considered an expense but a required
expense due to them creating the products that bring the revenue in. Shrinking
the expenses by shrinking the developer count occurs but I would think that
would have an impact later on the amount of revenue that could potentially be
generated.

In a non-tech company I agree with your statement. Likely the revenue is
brought in through some other avenue. A developer in that scenario is
defiantly seen as more of an expense to reduce.

Do I have a skewed mindset around this?

~~~
forgottenpass
_Do I have a skewed mindset around this?_

Every expense is a required expense. Every expense is looked at to be
minimized. They're going to run with the fewest, cheapest developers as they
think they can get away with to deliver what they want to deliver on the
schedule they want to deliver it. It doesn't always work like that, over time
bloat accumulates leading to restructuring/layoffs. This is so standard that
exceptions are notable (20% time, skunkworks, etc...)

------
jfc
I would add: learn how to deal with the XY problem -
[http://meta.stackexchange.com/questions/66377/what-is-the-
xy...](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem)

Will save you alot of time at work, and in life.

------
geebee
A lot of this is really wonderful advice, though I disagree somewhat on one
point.

The good stuff first - I completely agree that a developer should look at a
maintenance project as a learning opportunity. I was lucky enough to get a lot
of researchy, green field projects early in my career. But I grew a lot as a
developer when I started maintaining, adapting, and modifying an existing code
base. My only real caveat here is that it should be a relevant project,
ideally an open source project. You'll be introduced to a lot of different
developers, and you'll get a really good sense of how to work collaboratively
with a lot of different people. There is a huge difference between a project
that says "there's an existing open source app - it's reasonably well written,
but it needs work and updating, and we need some new features" and "here's
stan's old pile of crap, keep it running." The first can be a huge learning
experience and great for building a network and career. This is the sort of
experience that gets you to a point where you may be able to get new
programming jobs without 3 references and several hours at the whiteboard
showing how to find a cycle in a linked list. A lot of people know you because
they have worked with you, and they know your code because, well, they've
reviewed your code and you've reviewed theirs. It really is a way to rise
above some of the unpleasantness of our industry.

Now for my disagreement. "Do this job because you love it." I'd be ok if we
added the phrase "as the thing you do for money." I don't think you need to
love programming so much that you'd do it even if you suddenly had 10 mil in
your bank account. That may be an unrealistic standard.

------
bejuizb123
Totally agree with the point about Learning to Communicate. Have seen the
'rock-star senior devs' think and speak so clearly with a variety of audience,
and on the other hand 'just-the senior devs' who struggle explaining what they
want to put across. Coding and communication should be complementing each
other, as both have their roots in 'what you think'.

------
strathmeyer
Whenever I tell recruiters or career councilors that I am looking for 'junior
developer' jobs they look at me like I am crazy, like such things don't exist
and that I don't and to work hard or do real software development. So it is
nice to know a decade after getting a Computer Science degree that such jobs
may actually exist.

------
neudabei
Great advice! I would agree with everything except maybe that “I just had to
hack something together…” always is a bad thing.

Especially from the business point of view this article stresses, it can be
reasonable to 80/20 your way out of certain problems and then polish it in the
future.

~~~
UK-AL
I also think it presents a highly optimistic view of the average manager.

~~~
icehawk219
As well as your average customer. Your average customer couldn't care less
about the maintainability, testability, or cleanliness of the code. They care
about getting the features they asked for within the time frame they were
promised for the price they were quoted. You could argue that those things all
play into that and are things they _should_ care about and I wouldn't
disagree. But the reality is they don't. If you tell them you have to push it
back because you need to clean up the code and make it look pretty you're
going to have an unhappy customer.

------
S4M
In the same vein:
[http://learnpythonthehardway.org/book/advice.html](http://learnpythonthehardway.org/book/advice.html)

------
enanoretozon
"Those who have passion will sustain"

oooor bills to pay...

------
gitspirit
I can vouch for every bit of this advice. Well written too.

