

Programmer's Dilemma - CoryG89
https://medium.com/i-m-h-o/231d7499a75

======
VexXtreme
When people tell me that I should "do projects in my own free time to keep my
skills sharp", it throws me into a fit of rage and makes me want to tear them
a new one. Do you see any other professions having to do that in order to stay
employable? Can you imagine lawyers having to practice law in their free time
to "keep their skills sharp"? Can you imagine civil engineers having to draft
plans for bridges and buildings in order not to "destroy their ability to make
a living"? Or doctors or any other high prestige professions doing anything
like that?

If the answer is no, then WHY THE FUCK should I have to spend my free time
maintaining a bunch of projects on Github just so I could keep providing for
myself? Is what I do in my day job not good enough anymore? Now I can't even
apply for a new job listing "backbone.js" as a requirement unless I have it
listed in my resume or have a Github project utilizing it? Whatever happened
to the notion of smart people being able to pick up and learn new technologies
on the job? You think it's okay to try to offload the risk and the time
necessary to pick up a new technology to an employee and their free time, vs.
providing the time and the resources for learning on the job?

Tell you what OP, you can take that attitude elsewhere, I'm not buying it. I
prefer spending my free time having great interactions with my friends and my
girlfriend, enjoying traveling and getting new experiences and just making the
most of this one life that I have. Now, If you believe that my system of
values is incompatible with yours/your company's, then I don't want to work
for you because you're an arrogant exploitative asshole with no respect for
other people and their time/life.

This is the way you should do hiring, if you happen to have any semblance of
fairness and intelligence:

If a senior person with a somewhat outdated skill set applies for a job, then
you're not supposed to test them on the latest technologies, you are supposed
to take a look at their track record and try to figure whether they are
generally a smart person and whether they were able to get things done back in
the day. If someone was a good programmer 20 years ago, then they will be just
as good now, if not better, because it's ultimately a person's intelligence
and attitude that determines how good a performer they are, not a list of
buzzwords on their resume. If you don't get this, then I'm sorry to say, you
probably aren't very bright.

Caveat: if you are moving extremely fast for some reason or need something
done IMMEDIATELY, then it makes sense to hire someone who already has the
skill set you're looking for. If it's a long term assignment/project, what
technology they know/don't know has no bearing on how good they will
ultimately perform.

PS. You have inadvertently confirmed everything another blogger wrote in a
post about why a career in programming ultimately has low prestige:

[http://www.halfsigma.com/2007/03/why_a_career_in.html](http://www.halfsigma.com/2007/03/why_a_career_in.html)

~~~
Fomite
"Do you see any other professions having to do that in order to stay
employable? Can you imagine lawyers having to practice law in their free time
to "keep their skills sharp"?"

This is a profoundly ignorant question to ask:

\- Lawyers _do_ essentially have to practice law in their free time. Many,
many state bars require continuing legal education in order to remain barred.
Can _you_ imagine having to _pay money_ for classes or be legally prohibited
from programming?

\- This is also true for doctors and nurses. Continuing medical education is
mandatory for both to be allowed to practice.

\- Most professional academics spend a huge amount of their "free time"
thinking about their field, reading journal articles to stay current, and
taking classes to stay current on new statistical software, programming
skills, etc.

~~~
TimSAstro
I don't quite buy your argument - yes these professions may work long days,
but generally the upkeep of skills falls into those allotted working hours.
Programmers should do this too, when it is helpful to their work. But
suggesting that someone should add a whole new project to their resume on the
weekend is akin to saying a lawyer should take on a pro-bono case just to buff
their CV. If they want to do that, more power to them, but it shouldn't be
expected of everyone.

As to academia... don't get me started. That is a strange and unusual
profession which lies somewhere between 'hobby as job' and 'slave until you're
tenured'.

~~~
jiggy2011
I don't know, most professionals I know spend at least some of their "free"
time (or at least the time they spend at home) reading journals or
publications.

The idea of a profession is that one is not generally paid by the hour for
"work" even if one bills a client by the hour so time spent on professional
development whenever it takes place is part of work and covered by a salary
rather than a wage.

Of course it might be true that other professions do less non-billable
practical work though this is probably more due to the fact that programming
doesn't require a significant budget.

The issue I think is one that many companies want programmers to work more
like wage laborers and take care of the professional side for themselves.

For example a law firm is probably more likely to allocate budget for
associates to use for professional development than an IT contracting company.

------
bcantrill
I've done kernel implementation for 20 years, and this question is absolutely
terrible -- unless the answer that one is looking for is an intelligent
explanation of why this is such a terrible question. It's an awful question
because the kernel may not be involved at all on a user-level call to malloc()
(e.g., a caching allocator like libumem or a traditional allocator that
needn't extend the break for a given allocation), may be involved in a minor
capacity if the break must be extended (on most systems, a system call and
some VM interaction), or could be involved substantially if the allocator is a
mapping allocator and page faults are induced (text and data) or scheduling
events or anything else that necessitates kernel involvement.

For whatever it's worth, when I have historically interviewed university hires
for kernel positions, the question I ask is much simpler; namely, what does "*
((int *)NULL)" do? Sadly, most university students -- even ones who have done
very well in their university computer science courses -- don't get this
right. And it's sad because it's not really the question, but rather just the
segue to the actual question: when a candidate correctly answers that NULL is
dereferenced and the program crashes[1], I ask them to write the program
(statement, really) in an assembly of their choosing (most graduates have MIPS
or SPARC on the resume) and I then ask for everything that happens between the
execution of that instruction and the resulting core dump and return of
control to the shell. With a qualified candidate, this could easily be a
multi-hour jaunt through microprocessor architecture and operating systems
implementation.

All of that said: I don't really do that anymore, but rather look to a
candidate's open source works. The last kernel engineer I hired had done open
source work that was so impressive that my interview consisted only of me
determining that he had done the work himself -- which took all of 30 seconds
or so. (He had, I hired him and he's been an absolutely terrific engineer.)
Easiest interview ever!

[1] Except on AIX and any other asinine system that maps NULL.

~~~
gizmo686
>what does "* ((int * )NULL)" do

Technically speaking, that is undefined.

"If an invalid value has been assigned to the pointer, the behavior of the
unary * operator is undefined...Among the invalid values for dereferencing a
pointer by the unary * operator are a null pointer,..."[1]

[1][http://www.open-
std.org/jtc1/sc22/wg14/www/docs/n1124.pdf](http://www.open-
std.org/jtc1/sc22/wg14/www/docs/n1124.pdf) page 79

~~~
bcantrill
Yes, yes. What I _actually_ do is write about a five line program which --
absent fancy alias disambiguation -- can't be optimized out of crashing.
You're hired, okay? ;)

------
onan_barbarian
There is a fundamental disconnect of reasoning here. What we are expected to
believe is that these people at their "big, name-brand companies" are carrying
on an elaborate hoax on their employers and their inability to do blank page
coding exercises reveals their fundamental uselessness.

Possibly, the truth might be that the majority of serious work is done under
conditions where you are used to your framework and, frankly, can easily
forget how exactly to fire up a editor and write code to solve a toy problem.

One might say this reflects more poorly on the interview process than the
interviewee.

The idea that there is some special magic "creativity" involved in this kind
of blank sheet programming that is never required when programming within a
well-established framework is pure hokum. We have a lot of well-established
practices in our code base that allow us to bust out a new and sophisticated
graph analysis or transformation in precious few lines of code - meanwhile,
the blank sheet guys are self-congratulating because they know how to call
glib's hash functions in a clean sheet environment. B... F... D... (and I
don't mean the library)

------
pcunite
I applaud the author for bringing up this point, however, there is only so
many hours in a day. The developers in question are probably not 30 years old
anymore. They were cool once too ya know. Instead of bashing them for not
coding and drinking Mountain Dew till dawn, why not see if they are willing to
learn again ... _on the job_?

Be careful young bucks ... you're looking at yourself in 10 years. The fix to
this is company development programs ... _not_ doing fake interviews (for
real?) and switching teams.

~~~
karlkatzke
I can only speak to US-based IT jobs, but there's a really distinct problem
with the industry here.

There is a decent supply of bright young things coming out of school who don't
know things, but know that they don't know things, and study and bust ass on
stimulants to make up for it -- coding all night on Dew.

By the time those bright young things are 30, they have probably given up the
Dew because they have high blood pressure, and their evenings and nights are
taken up with family duties.

It's an all-or-nothing approach; spend all your waking hours on your job, or
have a life. One's healthy, one isn't. One will keep you employed in the IT
industry past 40, the other won't.

And yet, we hear IT companies complaining that they don't have enough talent
and trotting out the old "old programmers can't learn new tricks" schtick.
Instead of developing the employees they have, they want more input into the
front of the system while they shuffle the 90% of programmers who don't become
"greybeards" and aren't "management material" off into suboptimal jobs doing
4-hour response hardware service.

------
zhemao
Although the article as a whole makes very good suggestions about keeping your
skills fresh, I think his standards for the candidates he interviewed are
impossibly high. Expecting an understanding of what the kernel does when
malloc is called is probably fair (actually I think this is a trick question,
as I believe the kernel doesn't actually page in any memory until it is
accessed for the first time). But I don't think anyone without superhuman
coding chops would be able to implement an LRU cache framework in one hour
using a C library they have no experience with.

~~~
plorkyeran
A simple LRU cache is not very much code (certainly less than 100 lines even
in C). Assuming the hash function in question has a sensible API, getting
something that works but has a few bugs and performs suboptimally should not
be at all difficult for an experienced programmer who knows what an LRU cache
is.

~~~
vladimirralev
While I agree with you, writing a crappy LRU will be a poor indicator of skill
for a senior developer or architect. It will be just a pointless and useless
piece of code. My guess is that the author asked for production-ready high
quality code. I know that I've been asked many times for production quality
code in interviews.

~~~
nikster
If I was the interviewer I'd just check how they go about it - do they just
start typing or do they read the docs, that's a big one right there. I
wouldn't expect bug free code, just a reasonable attempt, clean code, and
something that generally works because a LRU cache is really simple.

I disagree it's useless - if I have a senior developer, they better know how
to do the basics. Otherwise what are they good for?

~~~
vineel
What's the right answer here? Should they start by typing or reading the docs?

------
invalidOrTaken
He's abrasive, but I _really_ think michaelochurch is on to something here.
Why are programmers old hat at 40, but not doctors? Answer: because it's
accepted that doctors have to spend time sharpening their skills: reading
journals, attending conferences, etc. This is not true at all of programmers
("The book said you could learn it in seven days. How hard can it be?").

Programmers sell themselves short.

~~~
borplk
Although I partially agree, medicine and things that doctors deal with does
not move nearly as fast as computig/software engineering.

I think the most important factor is the "virtual" nature of
computing/software. In a relatively short period of time you can wipe
everything and start from scratch.

~~~
jerf
If you do it right, by the time you hit 40 you understand that programming
_doesn 't_ actually move that fast. The superficialities are churning rapidly,
but there's an underlying truths are quite stable. They are moving, too, but
much more slowly.

For instance, take JS frameworks. On the one hand, they're churning so fast
that nobody could possibly keep up with them all. On the other hand... they're
all just shuffling the same basic primitives around in various combinations,
and exploring spaces hardly any different than their desktop brethren 20 years
in the past. There have been cases where I've successfully predicted the
failure case of the latest JS wonderthingy just by listening to how it works.
For instance, five minutes after I heard Node described I knew about Callback
Hell, even though the term as such did not enter the lexicon for about another
year and half. I could also tell you exactly what the proposed solutions were
going to be, what their advantages and disadvantages would be, and almost
completely called what order they would be tried in, because it was all just a
recapitulation of experiences had in other communities. From the surface it
looks like Node has been in wild churn, with more understanding it's merely a
turn of the wheel of history.

As an example of the other side, DRY isn't going anywhere, and developing your
DRY-vision is the work of a decade. (It goes way deeper than most people seem
to realize.)

------
c0deporn
Interesting article. I actually have a talk that I give about this exact
issue. I laugh at anyone [developers] who calls themselves an "expert" unless
it's followed by a very specific, narrow topic.

I dislike the title "Senior" when discussing developers because it's usually
just a title given to those who have 1) been there there at least 3 years or
2) Have n years of development related experience on their resume. The problem
is, the title is associated with level of assumed expertise. As the article
says, these guys can barely answer a basic question.

However, that's not to say that they don't know how to be productive or
produce quality results.

It wouldn't be so bad if developers just went out and read someone else's code
or attended a code camp or user group, but they don't.

------
benjaminwootton
Its hard not to fall into this situation even if you work for startups or
small companies.

Say you arrive on day 1 on a greenfield project. You will soon be fitting in
with other developers patterns and spending time digging into code thats not
your own.

Even if you are the lucky one putting low level frameworks and architecture
into place, that eventually stabilises too snd you move on to more typical
work at a higher level of abstraction.

As time goes by, your knowledge of the code, product, domain, organisation,
market etc continues to grow. In a matter of weeks, you then have outsized
value to that particular organisation vs starting off as a generic code monkey
somewhere else.

This is not a trap or a dillemna, its just the nature of team based software
development. To not acheive this in each of your roles would be a bigger cause
for concern!

I would say, if you are hiring someone to work on your big complex legacy
system, you should probably attach some value to the fact that the candidate
may have proven expert in exactly that scenario over the long haul in their
previous role.

Succeeding in that environment takes a certain skillset, and its disingenuous
to reject people for not knowing certain low level programming constructs that
they wont even be using day to day. (Kernel work is one exception to this.)

------
cptFalco
It is kind of interesting seeing the difference between approaches that other
tech interviewers use - the following was one that I saw today on linkedin:

[http://firstround.com/article/The-anatomy-of-the-perfect-
tec...](http://firstround.com/article/The-anatomy-of-the-perfect-technical-
interview-from-a-former-Amazon-VP)

I think that it needs to be a combination of 1) what is on your resume as you
become an expert in a fairly specialised piece of technology and on 2) general
knowledge.

I feel a bit sorry for the guy who had to write the LRU cache. I have been in
unfamiliar surrounds before and come across as a blathering idiot, and I
didn't feel it was 100% my fault. The interviewer has some responsibility in
trying to understand the background of the person, and is not there to show
how smart he is.

------
rabino
Maybe programmers rotating every 2 years is what drives companies to have more
and more stable frameworks.

------
chidevguy
Completely agree. The other problem I've seen with getting stuck on the same
project for X years is that you'll have a very limited portfolio to show for
it, unless you're working on side projects as well.

~~~
kb19
If you are on a project for a few years (and aren't doing just maintenance, in
which case I'd GTFO) you should be able to show a roadmap of where you took
the project, its success etc. which might not be so bad.

------
nikster
Two observations:

\- The worst programmers work for big corporations. Because there the overall
level of competence is so low they can scrape by barely doing anything.

\- Very true about keeping skills sharp and developing new skills. It's hard
to do and hard to keep up but always worth it.

~~~
mdkess
MORE programmers work for big companies, so you get a full normal
distribution, and I would imagine there's a bias toward interviewing more of
the ones who got fired or poor performance reviews. You only see the tail.

------
rogerbinns
This is also the source for some of the fizzbuzz issues. It is astonishing how
hard some people find it to make a computer print one through one hundred,
never mind adding the flow control correctly.

------
rvijapurapu
Most good developers can barely remember a line of code, they usually have a
general idea as to how you could implement aspects a concept and build on it
as they go. Incremental changes

------
tled
"We are captives of our own identities, living in prisons of our own creation"
\- a quote by T-Bag in Prison Break

------
mikeash
This is part of why I just occasionally reimplement chunks of existing
libraries. It's fun, gives me something to write about, and keeps me sharp.

If the only goal is to push the current project out the door, then
reimplementing a hash table or a chunk of printf is pointless. But that sort
of thing from time to time keeps you from treating all these things as opaque
black boxes.

------
wyclif
I wish people would use spell check when they write headlines for blog posts.

~~~
67726e
Cut him a break, English is clearly not his first language.

~~~
ojbyrne
I'd be inclined to cut him a break, except that he doesn't seem to cut a break
for developers parachuted into his milieu.

The situation seems quite analogous.

~~~
karlkatzke
I disagree. He cuts them a break: he gives them the opportunity to interview.
It's up to them to make something of it by proving they have practical
experience.

