
Great developers are raised, not hired - eduardsi
https://sizovs.net/2019/04/10/the-best-developers-are-raised-not-hired/
======
msluyter
I officially mentored someone at my previous company and helped him move from
a support tech role into a software dev position. It was incredibly rewarding.

But to play devil's advocate for a moment, isn't there something of a natural
disincentive to level up one's employees in such a tight labor market? To
follow the author's analogy, by mentoring someone, we're effectively "adding a
fish" to the pond, and if someone else "catches" the fish, that effort is
largely wasted. One might argue that if _everyone_ put more fish in the pond,
then we'd all be better off (true), but we have a standard collective action
problem where the free riders benefit at the expense of the fish growers.

I see two (partial) ways out of this trap.

1\. Pay more than everyone around you. (Obviously, not generally viable.)

2\. Make the culture of your company so awesome that people will want to stay,
even if you can't pay the most. Make mentoring/growth a central strategy _at
every level_ so people will see a path to grow.

I'd be curious to hear other possibilities.

~~~
wccrawford
>To follow the author's analogy, by mentoring someone, we're effectively
"adding a fish" to the pond, and if someone else "catches" the fish, that
effort is largely wasted.

Even more curious is that IT culture is basically that if you want to get paid
what you're worth, you have to quit and go to another company.

So these companies put all this effort into raising a better developer, and
then refuse to pay them what they're now worth and basically force them to go
elsewhere.

It's not "what if they go elsewhere" under that situation, it's "when".

I'd argue that you don't even have to "pay more than everyone around you".
Simply coming close to parity is enough to stop most people from going through
the pain of a job search. But these companies don't even get that close.

The last time I switched jobs, I got a 40% pay increase. That's ridiculous. I
even told the company I was underpaid and they asked if I could wait a year
for a raise. I didn't even answer the question. I just walked away and started
looking for a job.

They weren't surprised when I found one and quit.

And a couple weeks before I left, they put in a job ad for _7_ developers,
offering what I was making at my new job for each of them. I've been at this
new job as a senior developer for 8 years now.

Could I make more? Almost certainly. But they gave me decent raises and have a
good culture (almost zero overtime in 8 years) and benefits, and I don't feel
like leaving.

~~~
salarycommenter
Currently switching jobs for a personal record 57% increase in total
compensation.

And I was NOT poorly compensated before. I was already in the 99th percentile
for individual income.

The harder I push on comp the more I get each time.

I am not going to lie and say that it didn't take years to build to this point
in terms of skill, work record, professional network, and interview ability.
It took three FAANG companies bidding against each other.

Meanwhile I get offered nothing in terms of growth from every employer I have
ever worked for ever. Literally never happened my entire career. Just this
time after I already had an undisclosed offer in hand I got a promotion with
no meaningful compensation increase. It was the first promotion of my 15 year
career!

Sure they were willing to match, but who wants to try and soak blood from a
stone.

~~~
luminati
Off topic - but your username and the vast majority of your commenting history
is primarily on salaries. Curious - is there some backstory to it? Feel you
got severely underpaid?

To each and his own, but bay area engineers pissing about making ONLY 300K has
always come off as being a bunch of spoilt brats - especially considering the
vast majority just gem/npm/pip install this and that and glue all the code
together. Of course the market deserves to pay accordingly but I think it's
just a big bubble that's going to crash soon - since there is a huge mismatch
between demand and supply of CRUD glue programmers (which most programmers
are).

My guess is that once Lambda School, Make School, ISAs all become mainstream
and the pool of CRUD glue programmers matches the demand all salaries will
come crashing down. I think overall it's a good thing for society in general
(and especially the tech towns).

ps: Pardon my tone. I work in the space industry. Maybe I have an axe to grind
;)

~~~
salarycommenter
This is an alt specifically for discussing compensation because I know it
elicits that reaction and I don't want that associated with my professional
identity.

I think discussing compensation frankly and openly is very important. People
have no idea what is possible. Two people on the same team at the same company
can have wildly different compensation. My goal with this alt is to get people
to take the biggest slice of the pie they can for themselves and avoid wasting
their precious time doing lousy work for lousy money.

I have wasted a lot of time and life opportunities working for less then what
I am capable of getting. I wish my future self had been around to tell me to
push harder and be more mindful and efficient with my time.

I don't think CRUD glue programmers are at the top of the market right now.
You could flood the market with them and it might not move compensation for
people in my space. Even so, that is just another argument for pushing hard
right now. Strike while the iron is hot. No one knows how long this will last.

~~~
oarabbus_
Any advice on learning your true worth? Assume for a minute that Glassdoor is
useless, as the "salary range" it displays shows that the maximum is 2-2.5x
the minimum.

~~~
manfredo
There is no "true worth" that you can look up on a website. Your salary is
your cost in the labor market. And like any market, worth is determined by
what people are willing to pay. Go out and interview, get some offer sand see
who is willing to compete for you. That's how you get your true worth.

~~~
code_duck
Right, the entire point of the question is to find out what people are willing
to pay.

------
rb808
> Your mentees will support you and promote you for the rest of your life.

The problem I've seen is that this is rarely true. We've had a big set of
grads we've trained that quit for a 20% pay rise, or a project that they
happen to like better. Many regretted it but it didnt stop the next guys from
doing the same. I'm really burnt out over teaching green newbies again and
again.

~~~
chrisseaton
Why don't you match their pay rise?

Or give them projects they're more keen to work on?

~~~
vetinari
Usually, the teaching/mentoring is not free either.

So you can a) hire someone who needs training and then train them, or you can
b) hire someone who is productive since day 1.

The people in a) cannot expect the same salary as b). Otherwise, there would
be no point in incurring the costs of training them.

Unfortunately, once you train them, someone can snatch them as people in b).
You incur the loss, someone else benefits.

~~~
brandall10
This is simple - pay people by the value they bring to the company upon every
annual compensation review.

Yes, it costs money to train people. Consequently they get paid less during
that period. But once they can fly on their own, treat them as if you hired
them like that.

~~~
vetinari
> Consequently they get paid less during that period. But once they can fly on
> their own, treat them as if you hired them like that.

That's too early. You made an investment, that investment has to break even.
With your suggestion, it would never break even.

~~~
brandall10
With all due respect, if hiring an entry level dev is a _loss_ for your
business then perhaps don't hire them? A dev should be a net gain regardless
of skill level.

You pay them market when they need to be trained, you pay them market when
they move up the skill food chain.

~~~
ebiester
And as such, junior developers don't get hired, because the first 2-3 months
of their career, a junior developer is at negative productivity, considering
the work the team is doing to start getting them up to speed.

Some of HN works in areas that are harder than the bog-standard CRUD app. So,
do you give up on hiring junior developers at all? I believe our whole
industry suffers if we come to that conclusion.

~~~
brandall10
This whole CRUD app crap is a cop-out - please don't insinuate it's my lack of
experience that has me making this assertion. I've been an engineer for 23
years and spent the first 16 years largely working on large enterprise systems
in C/C++, then C#, primarily in the health care space often with some hardware
component. Regardless, the work I've done over the past 7 years with modern
web tooling is some of the most difficult I've done in my career.

It's a failure of the organization to not utilize entry levels from the first
week. At any company. After all, the FAANGs of the world have a different bar
of entry.

People keep talking about this like you're literally training people how to
program. That's BS. Every org has refactor work, tests to write, processes to
improve, tasks to research, low hanging fruit bugs to tackle, systems to
blueprint, all sorts of stuff that's a strain on the more sr. staff that's
been pushed aside but needs to be addressed. You can strategically bring entry
levels up in a way that's a net gain in any environment.

~~~
ebiester
The truth, however, is that a senior developer is $140,000 and a junior
developer is $80,000, and that same junior developer will be $100,000 in two
years. (This is assuming salaries in one market.) That junior developer will
take 3-4x the time to handle the same task as a senior engineer, and will take
some of the senior engineer's time to guide the solution, provide feedback,
and mentor.

That doesn't mean that we shouldn't hire junior developers - in fact, it's our
duty as an industry to hire and mentor. However, it is with open eyes knowing
that junior developers are not cost efficient in many areas for the first
year.

But we go back to the original statement: "With all due respect, if hiring an
entry level dev is a loss for your business then perhaps don't hire them? A
dev should be a net gain regardless of skill level."

If you have $320,000, and can have 3 junior developers or two senior
developers with the same budget, the 3 junior developers will be a net loss
for the first year. They can be productive, but you have to compare on budget.

___

But I find that as a bizarre set of work that you call out.

* Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback.

* My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers.

* I'm curious what processes you see that junior developers can improve.

* Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break?

* Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit.

* What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.

~~~
brandall10
Pretty much all the things you call out as bizarre I've seen some better
interns slice right though.

* Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away.

* Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance.

* Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task.

* Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up.

AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the
work that needs to be done. If you run as tight a ship as you imply the sr.
devs will be a better bet every time from a value basis - but that's rarely
the real world. I wouldn't add more than 1 junior at a time to a team of < 6
devs.

Lastly, addressing "that junior developer will take 3-4x the time to handle
the same task as a senior engineer". Well duh, don't give juniors the same
work as your seniors. The whole point of hiring lower level staff is you have
work that is better suited for lower level staff, or rather, work that is too
costly to give your sr. staff. This whole it's our duty to train the next
generation... you're running a business, not a charity. And then you get
caught up in this cancerous notion of people being in debt to you because you
don't know how to properly utilize them.

------
iandanforth
The distinction here is between a hunter-gatherer mentality and an
agricultural one.

Are you picking and choosing or are you farming?

Currently we _grow_ engineering skill in (often) high cost institutions with
limited capacity such as traditional universities. Moocs and bootcamps are
alternatives which try to address the scalability, cost, and time commitment
barriers of traditional education.

The question is should there continue to be a strong dichotomy between
organizations who consume the output of these growth channels and the growth
organizations, or should software development companies create programs of
structured education and growth that have a low barrier to entry?

As others have mentioned startups who can hunt/find/pick people with relevant,
high quality skills have the advantage of not paying the time and
organizational cost of training.

Personally I think that large organizations should be taking more hands-on
approaches that take all, or nearly all comers, and then provide training for
the kinds of skills they need.

If you look at military funding for medical educations (for example) you'll
see that the organization can be very generous in terms of time and training
cost as long as a candidate ends up with the skillset they need. You might not
go in wanting to be a urologist, but you can end up highly skilled and very
well paid if you're willing to meet the needs of the organization.

------
EliRivers
I have, to some degree, given up trying to hire senior developers. Instead,
I'm doubling down on the internal training programme (and have hired extra
juniors).

5% of time is set aside for training. Works out a little over a half-day every
fortnight - every fortnight, after lunch on Friday, drop the code and hit the
books, pet projects, videos, experiments, whatever clearly makes you a better
software engineer. If you _don 't_ spend that time on your own training,
questions are asked. Nobody has been fired for not training yet, but if we get
someone who simply refuses to, I could see it going that way; when we hire
someone, we're not just hiring that person today - we're hiring that person
next year, and we're banking on that person next year being better at this.

There is CapEx for books. We have PluralSight licences. New starters' agreed
objectives include reading and thence using "Effective C++"; I _will_ come by
your desk every so often to chat about parts of it. We have short
presentations every fortnight (the time of which doesn't even come out of the
5% training time) on technical topics. Once you've covered the basics, the
company starts contributing towards conference attending.

The last senior dev who got internally promoted currently has an allowance of
50% of his time for helping more junior devs understand things. Fifty percent!
The intention is to get his senior dev knowledge and experience out of his
head and into the heads of five other people; growing ourselves five more
senior devs.

I got all this by asking for it. Grow your own. Everyone wins. The company
wins, the employees win. Just had to ask; if you ask, and your company isn't
interested in improving, isn't interested in producing better products, faster
and cheaper... well, is that really the company for you? :)

~~~
anarazel
Maybe I'm just a grump, but: 5% is pretty low number for training people up.
Perhaps that's just the "hit the books on your own, but during work time"
portion? If it includes other things (talking people though a project that's
on the edge of their capabilities, discussing the architecture of important
project from an educational perspective, ...) then it seems pretty low.

EDIT: non-phone spelling

~~~
maxxxxx
5% is pretty low to basically nothing. I agree.

~~~
EliRivers
It's very low and, from my own experience, significantly higher than average.

My experiences are almost entirely UK based, outside big name or hip
companies.

~~~
maxxxxx
True. Usually training is 0%.

------
neilv
We're in a labor market in which CS students are focused on drilling for the
FAANG-style whiteboard tests. And many will tell you their strategy is to go
to Google for 2 years of experience and resume-building, and then leaving
rather than grind away and play the promotion game there. And everyone has
known for 20 years that you have to job-hop to grow your salary in this
industry. And most employees would be naive to think that their employer would
take care of them long-term.

In this mercenary environment, loyalty doesn't go very far, so, for retention
after mentoring, I assume one would have to pair mentoring/training with
substantial growth in compensation. Besides all the non-monetary attractions.

~~~
freyir
My last company would insist that they couldn’t give promotions or significant
raises. Until you came in with an outside offer, then they’d roll out the red
carpet and bend over backwards to keep you.

It breeds distrust, discontent, and disloyalty.

The best people don’t like this and leave. They company is left with people
who can’t land outside offers. And the company ends up needing to pay market
rate anyway to replace the good people who left.

Idiotic.

~~~
msoad
This works for the company because most people don't bother interviewing and
coming up with a counter offer. In my previous company the best of the best
would leave because company had this blanket policy that they would never do a
counter offer. But in overall it was good for the company because they were
able to retain most of engineers with raises as little as 1% and no stock
refreshers.

~~~
freyir
I actually prefer that policy. At least they stuck to their guns.

We had an inexperienced junior dev come in with an “amazing offer.” This
signaled to management that he must be amazing, so they offered a promotion to
team lead to keep him. Half the team quit within a month, then he proceeded to
run everything into the ground.

There was a certain amount of shadenfreude watching that play out.

------
rajeshp1986
I love the point the author raised in this article. Companies are spending a
ton of money on recruiting and paying commissions to recruiters. If some of
that money and effort is channelized toward mentoring, a company can notice a
significant change in quality in its workforce. That said, this article fails
to address 2 major issues or provide any solutions for that:

1) Every decent size company spends for providing resources like books,
learning portals etc. for their employee to grow their skills. There is an
entire industry running which caters to provide companies learning tools, for
example - safari online books etc. Mentoring is also used a buzzword in these
companies. There is a difference between providing tools & books vs creating
an environment where people can grow. Mentoring is very inter-personal. Unless
companies create incentives for senior engineers to help mentor other
engineers there won't be any real change to the way things are now.

2) If your teams or Orgs are always battling to meet the next deadline, how
will mentorship happen? You can't expect people to put more than 40 hours of
work and expect them to personally mentor other engineers(They still do btw).

------
julius_set
This article assumes that the person you are mentoring is open to being
mentored. I’ve worked with some engineers who were definitely junior despite
having years of experience and very opposed to even a slight suggestion on how
to improve their thinking process or implementation process.

~~~
ozim
On the other side of spectrum there are those people who "really want to learn
real programming" but you have to do all the work for them. You point them at
the resources, contribute ideas and it turns out person is not following
through even though when they talk they are enthusiastic.

So basically you have to somehow spot right person to spend time with, and it
is hard. At least guys that don't want to be mentored are not time sinks.

~~~
julius_set
This too, I’ve also worked with people like this, it is extremely frustrating
to teach someone who wants to be mentored not take your mentorship advice and
continue to make the same mistakes.

The counter argument here can be that I possibly may not have mentored the
person in the right way using the right motivation, but methods I tried were
(ranked in succession):

1.) Showing by example but asking to come up with own examples 2.) Templating
examples 3.) Listing out steps 4.) Finally just directly asking to do x, y,
and z

Utilizing data patience time boxing.

This is definitely a difficult problem I don’t particularly have an efficient
solution to, my best answer is just find someone to mentor who will execute

------
twoquestions
This sounds like a wonderful idea in a business culture _not_ obsessed with
burning tomorrow to a crisp for more return today. Not to mention this
requires trust and loyalty, both rendered cruel jokes by the all-against-all
knife fight that our (in the US) labor market is.

------
thom
At what size of company does this pay off? My experience of hiring juniors is
generally that they are net negatives to productivity for quite a while, and
the smaller the company, the more significant the impact of that is. How do
people here go about mitigating that?

~~~
mixmastamyk
Don't have proven techniques, but have been toying with an idea I'd like to
try the next time I have the chance.

Have been thinking of starting a "farm team" to develop green programmers.
Have a meetup once or twice a week, work on a focused project together, do
mutual code review. Read the classics (e.g. the MMM) as homework.

Perhaps give out some Amazon gift cards for good work. When a participant
levels up, move them to a paid role.

~~~
theonething
What is the MMM?

~~~
dragonwriter
_The Mythical Man-Month_ , by Fred Brooks

[https://en.m.wikipedia.org/wiki/The_Mythical_Man-
Month](https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month)

------
didibus
This seems to strike a chicken and egg problem. Who will grow the talent? It
seems you'll need to hire the mentors for that. And what's the level of growth
possible? Isn't that capped by the level of your senior devs?

As far as I know, most interview processes are designed to hire potential. For
example, if you can't learn fundamental algorithms in a reasonable amount of
prep time to prepare for the interview, but someone else could... Which talent
has the most likely potential?

I'd even go and claim that the current interview processes are biased against
senior talent. Someone who already knows they are qualified won't be motivated
to go and practice fundamental algos that they haven't needed for real work in
years. They'll expect their own track record and knowledge to be recognized on
it's own. But, the interviews won't care about that. And they might instead
hire a junior with more time and motivation on their hand, which decided to
spend all evenings for the last two months doing leet code questions.

Similarly, many companies seem to favor new grads, which they can quickly
brain wash into their existing engineering culture. They think, these new
grads really strive, instead of challenging the status quo, they internalize
our processes and work hard to deliver, even if we're being unreasonable.
Eventually, this creates a lack of perspective in the entire company. Hiring
more external senior talent would help get more perspectives, and prevent this
silo of opinion that hurts innovation over time.

~~~
dfrage
> And what's the level of growth possible? Isn't that capped by the level of
> your senior devs?

Senior devs who are good at mentoring also ought to be good at learning new
stuff. They'll also be learning some things from the mentees, at least some of
them will know stuff they don't know because our field is so vast.

Once the mentees catch up? If you've inculcated a learning culture, these new
senior devs will be learning new things right along with the old ones.

------
kgraves
I have never seen a single company/startup place a job posting for a junior
position, (lucky if they even say training)

Last time I checked, everyone wants to look for a senior developer with 5+
years of experience. It's some sort of hidden bonus if you're from a FAANG
company as well.

I'm guessing everyone wants to be the next Google, Facebook, Amazon, Netflix
or Uber.

~~~
cimmanom
so they do want junior developers. They’re just giving them the “senior” title
ridiculously early in their careers.

What no one REALLY wants are ENTRY LEVEL developers, who tend to be a net
negative to productivity for roughly the first year or two.

~~~
bpicolo
Every new grad, intern I've worked with has done an amazing job hitting the
ground running. They're not ready for "here's a big problem, please dream up a
solution and get it out the door", but with reasonably laid out tasks they do
a fantastic job working out the code and improving their technical chops along
the way.

Juniors who are eager to learn are my favorite employees

~~~
0xffff2
>Every new grad, intern I've worked with has done an amazing job hitting the
ground running.

You've been incredibly lucky. It's great when it happens, but it's certainly
not the norm (speaking from experience at a well-known organization that hires
a _lot_ of interns).

------
yzfr12006
The article is not only on point but it reflects a big problem in the tech
companies.

Businesses loose millions and they just burn cash because of toxic and
arrogant developments teams.

I can quadruple the sales of the company that I work for but you cannot push
any change through the arrogant development team who don't give a chance to
other people, it is so pathetic.

~~~
amarkman
The problem in tech companies is arrogant and clueless management that treats
developers like dirt and blames them for everything.

~~~
JustSomeNobody
Trust me, there are arrogant developers out there and they suck to work with.
They treat code and design reviews as chest beating exercises. They refuse to
work on anything remotely legacy. If their idea or design gets questioned in
_any_ way they get loud and obnoxious. You can't mentor these devs at all.

~~~
0xDEFC0DE
>They refuse to work on anything remotely legacy.

You have to be careful what you're good at. If senior devs/management sees
you're good at legacy, they might task you with that as a majority of your
time. Then your career plans get sidetracked because you won't have as much
time working on the stuff that you want to work on.

Some developers are okay with legacy, but if they aren't, it's not surprising.
Some legacy stuff is absolutely horrible to work with - it devolves into "get-
in-get-out" fix mentality (and security issues usually get swept under the
rug). Some legacy products are good though and require minimal tribal
knowledge to actually work on.

This has happened to me twice at two separate positions: bait-and-switches
about what I'll be working on because more senior members wanted to offload
the legacy work themselves.

The general arrogance is really a separate trait from willingness to work on
legacy IMHO and I agree on those points.

------
austincheney
The best developer thing is really frustrating and ultimately a failure.
Companies always claim to want the best during hiring, but once hired that
completely goes away. What they really want are a couple good developers and
rest somewhere between mediocre to brand new.

To really see the paradox ask extremely controversial questions during the
interview. As a frontend developer ask about process efficiency or interacting
with the DOM without a bunch of framework bullshit.

------
projektir
So many developers here downright scared to mentor others. The problem with
the current job market on full display.

~~~
dfrage
We have to live in the world as it is, rather than what we'd like it to be.
The well reported in this discussion patterns of your boss trying to replace
you with your mentee, getting dinged for not getting "real work" done, and
mentees not staying in the company for very long should give anyone pause.

~~~
projektir
That seems like a good way to keep the world the way it is, and not how we'd
like it to be.

Thankfully, not everyone thinks as you do.

------
cva10
Ok, so the guy is in the training and conference business. That would seem to
skew his perspective.

Usually the people who talk loudest about mentoring are clueless or are in the
teaching business.

In the real world, there is zero reward for mentoring. Moreover, if you do it,
you might get fired and be replaced by the now cheaper mentee.

~~~
eduardsi
How can you mentor people if you are afraid of being fired or replaced by a
"cheaper" mentee? To mentor people, you have to be a professional developer,
at the first place.

Professional developers achieve job security by doing great work and making
themselves replaceable. Mediocre developers – by building knowledge silos.

~~~
dfrage
> Professional developers achieve job security by doing great work and making
> themselves replaceable.

Wouldn't that be "achieve _career_ security"? Because as I attest upstream in
this subthread, in my most notable example of being a mentor, I was indeed
fired as soon as my non-technical salesman background CEO decided I was
replaceable. Although he didn't realize that wasn't quite yet true, and the
mentee decided to leave instead of working in such a place.

I don't know about Estonia, but in the US conventional careers as a software
developer start ending when you're in your 30s, with 40 being a hard limit in
finding a new conventional job because that's when our national age
discrimination law kicks in.

That fresh out of college except for one short job mentee? The only reason
he's still a programmer a quarter century later is that within a decade he got
a high level security clearance, which is sufficiently onerous for the company
that pushes through that process, they have to "bench" or otherwise have the
employee work on non-classified stuff for many months, that after getting it
you're in a small pool that companies vastly prefer to recruit from.

This is intimately connected to being a good mentor since a fair amount of
experience is required to do a good job of it.

~~~
AnimalMuppet
> I don't know about Estonia, but in the US conventional careers as a software
> developer start ending when you're in your 30s, with 40 being a hard limit
> in finding a new conventional job because that's when our national age
> discrimination law kicks in.

In the US, I found a new developer job at 43, and another at 47. Haven't
looked in a decade, so I don't know how it goes at 57.

Caveat: I'm in embedded systems, which is a much more senior-friendly world
than web apps.

~~~
dfrage
As you say, you're in embedded systems, that's well known to be the other US
employment domain that's friendly to developers with grey hairs. Not a
"conventional" field.

~~~
scarface74
I’m a bog standard “Enterprise Development”. I found jobs within less than a
month at 34,38,42 and 44.

------
ohaideredevs
I have found the premise of the title to be completely false in real life. Not
much else to say to this - I haven't seen too many people grow, and when we
hire someone great, they are great.

~~~
JustSomeNobody
> I haven't seen too many people grow...

Are they allowed to? Are they mentored? It's not just one sided.

~~~
astura
In my experience, as a mentor:

Quite a lot of people are certainly capable of growing, but many (most?)
aren't. Either they aren't capable, or they don't feel like it.

Luckily you can almost always tell from the get-go who will grow and who will
stagnate.

~~~
ok_coo
Are they given time during normal work hours to grow? Are they given adequate
assistance and resources? Is training a priority?

I've run into two different situations in my work life: a) You should learn
new tech and keep up, but it's all on you, your own time and discretion
(outside of work). It was expected to do project work 100% of the time on the
job. b) It's expected for you to learn and grow and we will help you get
there. $ for training/conferences. It's expected that you will spend a decent
amount of time out of your 40 hr work week improving yourself and learning new
tech.

In situation A, I would have been (I was!) labelled as someone who lacked the
will. It was hard to put in a full day and do more at home, learning new
stuff. I still did it, but it was difficult. I was burnt out by the time I
left that job.

In situation B, I feel like I can live a normal life. I can learn, do my
projects (I'm more productive), and go home at night and enjoy my time off and
weekends. I feel like a normal person living their life.

Work/life balance is highly underrated.

~~~
astura
>Are they given time during normal work hours to grow?

Yes! Absolutely!

>Are they given adequate assistance and resources?

Yes! 100%!

>Is training a priority?

Its our #1 priority (for new devs).

Still got people refusing to grow. Ive been a very successful mentor to some
people, but I've gotten some real duds too.

I agree with the sibling comment that says 4 weeks is the sweet spot.

>You should learn new tech and keep up, but it's all on you, your own time and
discretion (outside of work).

That's ridiculous. I've never worked anywhere where you are expected to work
outside of work and, frankly, I just wouldn't.

------
habosa
Yes! This is something that is not just about developers and seems to be a
huge gap in hiring.

Go look at any big company job listings. There are many positions that have no
"entry level" roles. The lowest level of experience will say "5 years of {x}".

If you're a company that does not take people without experience, where do you
think they're getting the experience? You're relying on other companies to
train your employees, and naturally you're not getting a chance to create the
exact employee you need.

Hire people that are intelligent, humble, and willing to learn. Ignore
credentials, and promote from within. In most situations, you'll get the right
result.

Aside: The weirdest part is there are some positions that seem to not have
entry-level jobs anywhere in the industry, you have to sneak into them. For
example my girlfriend is a "Brand Strategist" at a web design agency. This is
what she always wanted to be, but when she was applying it seemed that every
Brand Strategist job required 2-3 years of Brand Strategy experience. So she
applied to her company in a role she didn't really want and then basically
talked her way into the new role. Obviously she's doing well and she will
never face this barrier again. But that was a stroke of good fortune.

~~~
AtomicOrbital
this is exactly what global investment banks do ... they hire a fresh crop of
a few dozen smart motivated young perspective programmers and put them through
9 months of intensive work study multitasking classroom lessons in software
problem solving together with IT operations experience where everyone gets a
very broad exposure to the technological landscape ... these banks repeat this
every 3 months with yet another new crop so there are three such sets of new
recruits on an ongoing basis ... after the 9 months these ~graduates~ are
assigned into programming roles and just boot themselves into their new
positions ... key here is they start with razor sharp people from any field (
philosophy, science, humanities ) who have exhibited problem solving potential
... also key is the business can afford to offer this in-house training while
the new hires are getting paid ... baked into this equation is the nurturing
of loyalty and admiration toward their employer - deservedly so I might add

------
analyst74
I don't think a general discussion on this topic can really be had.

In my experience of working for shitty enterprise software, good and bad
consulting firms (and seeing how their non-tech clients work), and silicon
valley startups. The company financials, work culture, job market are all
vastly different, impacting all the trade-offs of different hiring method.

i.e. some firms simply cannot afford top-of-the-market pay for senior
engineers they want to hire, so they hire more junior ones and train them, who
eventually leave after they're trained, but people don't immediately jump to
next ship paying a little more, so you end up getting good work out of them
for a period of time while underpaying them.

Some companies compete on non-momentary means.

Some pay top of the market rate, but only hire seniors.

Some pay top of the market rate, and hire from all levels; some of the juniors
rise up through promotions, and some didn't get recognition despite growing,
so they leave for other companies.

Some companies simply don't care about engineering quality, or does not have
the ability/DNA to differentiate between good and bad work.

Also in silicon valley, networking and mentoring good engineers is much more
professionally rewarding than in smaller markets.

------
abraae
I guess the cynic in me would ask what the point is in polishing a rough gem
in your organization into a diamond, if you're thus turning them into a target
for other people to poach.

~~~
alecmg
You get the first dibs, don't you? If you need a diamond level dev, you must
provide diamond level compensation. The article just points out that it is
simpler to get that level from other sources than filtering what is on the
market.

~~~
arvinsim
> If you need a diamond level dev, you must provide diamond level
> compensation.

It is baffling when companies resist against giving great developers a good
raise.

If they leave, the lost productivity and onboarding will cost them more.
Sometimes, they end up having to hire 2 people to replace that 1 person.

~~~
aNoob7000
Companies want talent for cheap. Every time I see in the news companies
complaining that they can't find employees, I think to myself, why don't you
pay more?

Add to that, if you start at a company and become a rockstar developer, admin,
or QA guy chances are they will not value you as much as if you came in as the
rockstar developer, admin, or QA guy.

------
man2525
That's roughly what they do at my company. Many people in the company have
some form of Computer Science certificate/degree, so shouldn't be that hard to
make them develop...but you hit the Peter Principle much faster in this line
of work. The CTO loves the hanging on by the seat of your pants optics. "Look
at him go. He doesn't have any idea what he's doing, but he's getting it done.
That's what we want." The rock stars puff up and grouse about the recent QA to
senior DEV promotion, then ridicule them, then you find out the rock star has
been working until past one every morning since part of their responsibility
as a lead is to make sure the QA-cum-Senior Engineer's work is code complete.
Then they leave. And yes, then a great developer is hired...but they never
tell us where they're going...

------
trailingZeroes
I agree with the headline and not much else.

Okay. I'm fine with agreeing with the notion that good, productive engineers
can result from good environments.

But that doesn't mean hiring 'broken toys' is a good idea. This article's
message is 'Can't find anyone good? That's okay! Hire someone anyway and
mentor them!'

Turn this stone into a diamond!' Okay. Some stones don't turn into diamonds.
Gee...if only there was some sort of process that can help determine which
people are capable of being a good engineer. Maybe companies can do something
like asking some basic questions about a candidate's ability. Something like a
filtering process.

'The pond is empty.' Pfff. No it's not. If no one's biting at the rod, it's
because of shitty bait.

------
yani
I recently asked a question where this answer would fit -
[https://news.ycombinator.com/item?id=19627404](https://news.ycombinator.com/item?id=19627404)

We have tried this with 3 different candidates: 1\. No experience last year in
university 2\. No experience with BS 3\. 1 year working experience

My experience with this approach is that it is a far more expensive investment
that takes long time to pay off. The safe ratio that I can recommend is 5
seniors to 1 junior

------
mixmastamyk
This discussion reminds me of the fixed vs. growth mindset, in the book
Mindsets:

"In a fixed mindset, people believe their basic qualities, like their
intelligence or talent, are simply fixed traits. They spend their time
documenting their intelligence or talent instead of developing them. They also
believe that talent alone creates success—without effort. They’re wrong.

In a growth mindset, people believe that their most basic abilities can be
developed through dedication and hard work—brains and talent are just the
starting point. This view creates a love of learning and a resilience that is
essential for great accomplishment. Virtually all great people have had these
qualities."

[https://mindsetonline.com/whatisit/about/index.html](https://mindsetonline.com/whatisit/about/index.html)

~~~
wincy
I started in IT. I very quickly realized I could do a lot of tasks the other
support staff weren’t willing/able to do, like learning regex and database
normalization. Kept getting more dev related tasks since my boss was the only
software engineer at the small startup.

Rather than get rewarded or hired as a developer by the company, as the
support team grew I was headed toward being promoted to the support manager.
They brought on someone else as a dev and that really made me realize I’d
never be a dev in the CEO’s eyes. Bosses daughter did an internship so she got
the coding tasks I would have gotten before. I was taking more phone calls
with idiots from places like The Federal Reserve who didn’t know how to Google
“hoe to format a hard drive”. So I left and doubled my pay.

Some managers just believe what you know is set in stone and you can’t
progress or learn anything new. It’s a really bizarre mindset to have when a
devs most important skill needs to be the ability to learn. Didn’t all these
same people go to school?

~~~
dfrage
> Bosses daughter did an internship so she got the coding tasks I would have
> gotten before.

In my experience at a couple of places, the moment you learn its a nepotistic
environment you should leave as soon as you reasonably manage. As you saw,
it's a sign of very bad management, the sort that can easily kill a company,
see Wang Laboratories for perhaps the most famous example in the US.

------
crimsonalucard
Great developers can be hired. For example, you raise the developer, I double
his salary and hire him away from you. Not saying that I advocate this
practice, but this is what happens in SV.

------
lkrubner
I can agree with hiring novices and then giving them what they need to learn.
We hired two women from Fullstack Academy (NYC) and they turned out to be
amazing. They were novices, but incredibly motivated and talented. Both of
them had had other interesting careers, and for both of them they were
changing careers to get into computer programming.

Now we are expanding the team so we are hiring another of their classmates,
who they have strongly recommended to me.

------
ausjke
from my experience the only way you get better salary is to jump around, not
too often, but if you stay with one company for two long(say, 5+ years), you
become the lowest paid at your level in general.

only if you're on the management ladder you want to stay longer, for tech and
engineering roles, the old employer does not really appreciate that much after
you're loyal for too long as far as compensation goes, very ironic but it's
the way it is.

------
rooam-dev
No, great developers are the result of ones hard work, long nights, dedication
and passion, hence hiring part.

Mentoring is Uni's job, since you pay them money.

------
teknologist
A “self-confident rockstar“ is just a developer who has been through this
process of self-development and no longer requires the mentoring and extra
effort to get them there.

I appreciate that some companies value experienced developers and aren’t
trying to nickel and dime by finding “broken toys” so to speak that they can
force into their own moulds on the cheap

~~~
epicureanideal
What do you mean by "broken toys"?

~~~
loco5niner
"broken toys" is referenced in the article.

------
loriverkutya
I would be really-really happy if the IT industry would just forgot about the
phrase, rock star. I just cannot read anything after I see that word.

------
asabjorn
Mentoring is the way to go, although the 18 month average stay in a job in
silicon valley increase the cost of training someone.

------
jasoneckert
I've always thought that great developers were cloned.....from Github ;-)

------
ezoe
Great article.

------
azangru
As a developer, I want to work with people who are at least as knowledgeable
as me, and preferably much more so. I want to spend my time learning what I do
not know, not teaching what I do.

~~~
poisonborz
You must be a junior with a few years of experience. Even so, you should
discover that teaching will boost your knowledge a lot. Being surrounded by
more experienced people may give you a short term boost, but teaching what you
already know will deepen your knowledge in what you only think you know, which
is way more important to improve.

~~~
azangru
> You must be a junior with a few years of experience.

You may say that, although that would stretch the word junior to the point
where it is hardly meaningful anymore. Judging by Twitter threads and Medium
posts that have become so very inclusive and protective of juniors, a junior
(usually discussed as applied to web development) is someone who has hard time
configuring build tools, is still uncertain about syntax of their primary
programming language, and is easily scared by a smidgen of functional
programming (such as the reduce function). I wonder where they would fit in
your classification :-)

