
How to be a great software developer - buro9
http://peternixey.com/post/83510597580/how-to-be-a-great-software-developer
======
gregd
I for one _loathe_ the term "Rockstar" programmer. For those of us over 40, it
connotes someone who is young, with no familial commitments, can work 80+
hours a week, only needs RedBull and Mountain Dew to exist, has no loyalty and
will burn out by the time they're 30.

I for one run away from any company looking to hire a "Rockstar" anything.
It's overused and abused.

~~~
jmagoon
Can we also add "Ninja" and "Genius" to the list of abused recruitment
buzzwords?

And don't even get me started on "passion". (David Mitchell's take:
[http://youtu.be/Bz2-49q6DOI](http://youtu.be/Bz2-49q6DOI))

~~~
webwright
I'll disagree with the last one. Whanever I hire for, I always look for
"passion for the craft" \- whether it's design, code, marketing, or whatever.
A great question is "What's the last book or blog post you've read in your
field that got you excited?" If people love what they do enough to explore it
in their off-time, they'll (usually) be a cut above the rest... And they won't
get bored/tired of their work as soon or as easily (assuming you can provide
interesting work).

~~~
johnward
Does that make it a negative if you're time away from work involves family,
outdoor activities, DIY projects, etc? I think that what you are saying is
what most people look for. Someone who writes code for a living and then goes
home to write code to relax. That generally fits the young, unmarried/no kids,
recent college grad stereotype.

I'm curious because I have been burnt out at work and decided to focus on
those things I mentioned. I'm much healthier and productive overall. Yet if I
went to an interview I wouldn't have hours of OSS commits on projects I worked
on after work to meet most job requirements.

~~~
dllthomas
I'm 30 (dunno if that's "young"), married, and write code to relax... kids
might change that though (or at least change how much time I have to relax!).
Not that I think everyone needs to work the same, mind you...

~~~
jwdunne
Kids don't change that. My little girl is 5 weeks old and I find much solace
behind my editor during quiet times :) It's reinvigorated with the hope of
whatever I learn I can pass down in the future.

~~~
ams6110
5 weeks is a piece of cake. Years 2-18 is where my spare time evaporated.

~~~
mihaela
I totally agree. Coding while monsters from cartoons and video games are
growling in the background. Or when my 4yr and 6yr old are fighting and a
teenager is playing loud music.

------
kamaal
On a side note, I asked a fairly successful tech professional->CTO->CEO what
it took be a great programmer/engineer. Ironically the answer I got was not
even related remotely to software in any way.

The thing he told me was that in all his experience, working with awesome
people he found that "working things on paper", gave massive clarity in most
projects. Human minds are not great at visualizing large stacks, diagrams and
lists. Hence writing down things, simplifies things. In fact when you write
things down. Draw that diagram, talk to yourself and refine your ideas on
paper in a couple of iterations. You largely solve that problem of reuse,
variable naming, problem identification. Agreed that some things demand you
play with code a little to proceed further. Yet, planning on paper solves most
problems which programmers face today.

Agile fashion unfortunately glorified many bad practices.

The more I pondered over that though the more I realized, how many bad
practices came into software development with this quick development-
deployment methodology. In the days of the past while you worked out some
documentation before you started a project, you often probed, visualized and
solved problems on paper. These days a lot of software is developed by the
time you realize its actually bad. By then going back is not an option and you
have live with it.

~~~
gtrak
I really like this comment. But I bet some folks gloss over a particular point
of importance.

For me, there's a huge advantage in literally using tree-paper, either for
code-reading, designing, taking notes, what have you.

It involves more of your senses, it's more tangible, every letter is written
with more care and the medium is incredibly flexible (maybe I feel like
drawing a circle on a whim, can't do that in emacs.)

It's better for scratch-pads than a text-buffer, imo.

Insights come more consistently and easily after iteratively marking up a
printout. It's just fully-intuitive.

------
sockgrant
A lot of software engineers don't realize that it's not about how much you
work, but how strong you work when you work. It's about efficiency, good
decisions, and total concentration.

\- Turn off e-mail.

\- Turn off chat.

\- Don't check hacker news. Or any website that is not for your current task.

\- Don't let coworkers interrupt you.

\- Get noise canceling headphones.

\- Have a goal to get through, and apply yourself to it completely.

\- Get very good at evaluating 3rd party code, then before you write code, see
if there's a library/native code that will do the work for you.

\- When you write code, if you _know_ the right way to do something, do it
right the first time.

\- If you're not _sure_ you know the right way to do something, then just get
the code out into the editor. After it's functional, take a look at the code
later and decide how it can be refactored. Refactor it immediately.

\- Don't write any tough code when you're not at your best mental capacity.
When you feel yourself mentally drifting on a hard task, put the code away and
go work on easy features. Work on your hardest problems during your best
hours.

~~~
subb
That's all very hard to do when your code takes 10 minutes to compile. Yes
it's C++.

~~~
lutusp
Have you considered running distcc on every machine in the building? It
greatly speeds up compiles.

[http://manpages.ubuntu.com/manpages/precise/man1/distcc.1.ht...](http://manpages.ubuntu.com/manpages/precise/man1/distcc.1.html)

Quote: "Zeroconf: This option is only available if distcc was compiled with
Avahi support enabled at configure time. When this special entry is present in
the hosts list, distcc will use Avahi Zeroconf DNS Service Discovery (DNS-SD)
to locate any available distccd servers on the local network. This avoids the
need to explicitly list the host names or IP addresses of the distcc server
machines. The distccd servers must have been started with the "\--zeroconf"
option to distccd. An important caveat is that in the current implementation,
pump mode (",cpp") and compression (",lzo") will never be used for hosts
located via zeroconf."

The above relatively new feature means that compiles will complete even if
some local machines go on and off line during the work session.

------
buro9
Two things always stand out to me:

1) Are you thinking before you touch the keyboard?

If you have the mental model right for data structures, patterns, networking,
caching, then you'll have fewer bugs. Get the mental model wrong, and one can
treat a bug as a code smell, it probably indicates a fire that you've just not
noticed yet.

2) As all bugs that have ever gone live have got past testing, Q&A and user
acceptance... are you better at reacting to the unexpected (bugs) than the
expected (testing)?

Bugs will happen, best to have great processes for when they occur.

I advocate insane measuring and monitoring which means thinking of
instrumentation when you author code. This goes back to thinking, as a team
and company one can fight the cargo cults with evidence. Monitoring and
measuring dramatically reduces the time it takes to react to an incident, and
guides which things should be tested in future.

~~~
buckbova
> Are you thinking before you touch the keyboard?

I can't stand developers who "feel" their way through projects. Take the time
to make a design document, whether it be a list of bullet points or pseudo-
code. Something is better than nothing.

~~~
davedx
With all due respect -- that is just how some of us work internally. We learn
by experimentation, intuition and repetition.

I often find it extremely difficult to write a design document for a system,
particularly a system owned by somebody else. I have written design documents
in the past, and they rarely end up describing the eventual system, no matter
how hard I work to maintain and update them.

In my experience, software design and engineering is an iterative process,
like gradually groping in the dark to determine the shape of a room. I cannot
simply turn on the lights and take a photograph of the room at the start of
the project.

Having said that, I completely agree that _in principle_ it is great to start
new projects with a complete design document, at least a functional
specification. Accurate technical specifications are a rare, elusive beast,
though.

~~~
AnimalMuppet
Well...

If you don't know what you're trying to build, you probably aren't going to
manage to build it. But in practice, you never actually know for sure, because
things always change.

You should know how you're going to build it (the architecture). But in
practice, my ability to be omniscient is very limited. As I implement it, I
find out that my design/architecture was wrong.

Maybe the key factor is this: When you find out that the architecture is
wrong, _do you fix it?_ Or do you just hack it to get the next bit to work?

~~~
davedx
> When you find out that the architecture is wrong, do you fix it? Or do you
> just hack it to get the next bit to work?

That's very project and organization dependent. Some projects are short lived
prototypes (I'm working on one now) that are for internal use only, so it
makes sense to try and get the damn thing finished without worrying too much
about architecture.

Other projects are built to last, or have very high quality requirements, so
you want to really get the architecture right, even if that means costly
rewrites.

~~~
BugBrother
(Reading this a few days later in an open tab. :-) )

Imho the most important thing is to have a good design document for the data
model. Partly because it often decides a lot of the structure of the code.

It is e.g. easier to rewrite code than realize that you lack some stuff you
_should_ have captured about customers years ago...

------
markbnj
I'm in an odd position on this one, because I agree with his list of desirable
practices at the end, and disagree emphatically with his idea that writing
something, anything, beats thinking about writing something 100% of the time.
Much of the "quick" code we write in the real world ends up enshrined the
minute it works, and never gets revisited or cleaned up. I once had to deal
with a piece of data import code written by a predecessor who had moved on to
management. He had a single 500-line try-catch block in which everything
happened. When I mentioned that this wasn't the most maintainable or
comprehensible approach, he simply replied that "it works." That statement,
"it works", is a pretty low bar in software, imo.

~~~
petenixey
I have to agree with that Mark. However there is (or a least should be) a
difference between writing something and committing something. It can be hard
to hold a manager off when you've got "functional code that's still a bit
rubbish" but getting to that stage first before going over the top can (in my
experience) massively accelerate development

~~~
markbnj
Agreed. The question is whether, in those cases where you begin with a "rough
version," you are afforded the time for refinement? Most clients don't
understand code, much less the difference between good code and bad. And very
few of them are equipped to evaluate the long term costs of maintaining bad
code. Hell, very few of _us_ are equipped to do that. So I remain very wary of
this concept that time spent thinking is time that could have been better
spent at the keyboard. Too often you only get one shot.

------
vinceguidry
Development is a creative act, everybody creates differently. I don't think
I'd be any more productive at four hours a day than I am at my current 2
hours. Some days it's closer to 30 minutes. Rare days push 5 hours.

At no time am I ever behind on anything. I often solve problems without
touching my laptop, sitting in my boss's office thinking things through.

I talk myself and my boss out of anything that looks like work. (He never gets
the hint and insists on working long hours. I'm gonna have to break him of
that habit someday.)

Things on my end run smooth because code isn't being committed every day and I
verify that it's working before I let it go. I happen to be a team of one, so
this is easy.

I've come to the conclusion that focusing on productivity is mostly a sham.
Before you do anything, spend half a day thinking about the necessity of doing
that thing, what consequences it'll entail, where it fits into your overall
plan, what you'll do if your approach is wrong and you have to backtrack, ways
to change your approach so it's more flexible, whether you might be trying to
solve the wrong problem and the problem you're having is actually social.
Nobody spends enough time doing this.

If you have to, use a checklist, and force yourself to do it before touching a
text editor. Don't think with a cursor and keyboard, guaranteed you'll find
yourself working prematurely. Better to fuck off than do that. I want to run a
software business where more time is spent on YouTube watching cat videos or
whatever than on writing code. Writing code's not cool, you know what's cool?
Erasing code. That's cool.

------
pyrrhotech
1\. collect paycheck. 2. save paycheck. 3. devote your time to more meaningful
and/or pleasurable pursuits.

Downvote away. Now, I don't dislike programming. As far as jobs go, it's
definitely on the better side. But there's a lot of things I'd rather be doing
with my time most of the time.

~~~
mattquiros
Nope, won't downvote, because depending on the team you're working with,
you're right. I work in a company where I started off following the author's
suggested actions for becoming a great software developer. However, I still
ended up being the difficult co-worker, the "dressage horse" as the author put
it. Just because I strongly felt about using classes instead of putting an
object's attributes in a single, vertical bar-delimited string. It works, they
say, and I'm over-engineering.

Of course my problem is about not being a good fit with the way the majority
of the team chooses to work and build software and perhaps the solution is to
just get the fuck out ASAP before I'm used to the mediocrity and acquire it.
But the working relations definitely got smoother when I kept my mouth shut
and just thought of the paycheck and used my time to go to the gym instead of
refactoring their code.

------
zwegner
I agree with most of the points of the article (finding a balance for testing,
naming, writing readable code, etc.) I'm not a fan of the tone, though. I
might consider myself a "rockstar" programmer, if not for the fact that it
sounds incredibly douchey. At least I'm closer to that than a "workhorse". And
yet I don't think I fall into the negative stereotypes he mentions... I guess
that explains my reaction (not to mention the self-quoting of tweets).

My biggest problem with software development as a profession is that people
don't think before they do it. I've found that a lot of people just hack away
randomly with some code that approximates their idea of how it should work. It
usually doesn't work, so they just change things aimlessly until it appears
to. I can definitely understand this mentality, I've been there--it happens to
me when I'm programming beyond my understanding. But I try very hard to
recognize when this happens, and stop to think more. There's very little value
in writing code that even the author doesn't understand. Accumulate enough of
this code, and you get the typical horribly-designed patchwork mess that
nobody can read, debug, or change.

To me, the ability to solve problems that you're not familiar with is
paramount in importance for actual software engineering. If you're just
building some CRUDdy business app that does nothing remotely complicated, OK.
But bubble sorts and link shorteners? Come on, that stuff is simple. Maybe you
never need to implement those specific examples, but as a placeholder for
general problem-solving skill, it's a low bar.

Perhaps that's why the title refers to "software developer" rather than
"software engineer". I don't really know. But I do wish there were more jobs
that required real problem solving skills (and don't require a PhD...).

~~~
CmonDev
> "But I do wish there were more jobs that required real problem solving
> skills (and don't require a PhD...)."

Isn't PhD just about having a bigger cook-book to use recipes from? It's not
like they are coming up with a new theory for every problem.

~~~
gvb
No, it means you've pushed the boundary out slightly.

[http://matt.might.net/articles/phd-school-in-
pictures/](http://matt.might.net/articles/phd-school-in-pictures/)

------
agentultra
I'm rather against the "working horse," methodology to software development.
Maybe it's because I'm lazy but I'd rather work with tools and processes that
let me achieve more with less effort. The "get it done," attitude is admirable
but ultimately, I believe, leads to the very same duplication of effort that
the author admonishes.

For example, you're building a web application that has a signup process and
the sales team uses an external CRM service to collect sales pipeline
information. The programmer who shows up and does their four hours pulls out
the usual libraries and writes the code to make it happen. The view fires up a
few requests in an asynchronous task that updates some models and everyone is
happy. However the sales team decides to change CRM services -- there's a
shiny new kid on the block with features that would improve their sales
process. The work-horse programmer gets the story and hunkers down. Four hours
later there are a new set of tasks, a signup function, and hopefully a few
tests.

The missed opportunity is that CRM software isn't terribly interesting and it
should matter little when the web application signs up a new user whether
you're talking to CRM A or B. I often find little scenarios like this that
just add up over time. They're often missed because the focus is on getting
something done for the next four hours/for the next sprint planning
session/whatever. There's no real planning done beyond the next little bump in
the road.

And so our solution is to use the same old tools and practices but simply hire
more people to be work-horses.

I'd much rather engineer more robust RPC frameworks that can negotiate the
protocols on their own so that a valid business decision to use a competing
service doesn't cost me a couple of days of boring, tedious work. I'd rather
just change a configuration line or two and sip an americano while reading the
latest Vanity Fair in my garden.

So.. while a great article in many respects I would add that in order to
become a great developer, in my opinion, you must refine your instincts
towards laziness. You must become a connoisseur in methods by which you can
avoid doing work. Being busy is not a virtue.

~~~
e28eta
I'm probably misunderstanding you, but your example seems like the whole
reason Rockstar programmers can be harmful to a team. I agree completely about
laziness and looking to the future, however.

* It sounds like the upfront cost is higher than the simple solution.

* I don't think changing the CRM is going to be a common occurrence, so don't optimize for it. YAGNI

* I doubt you'll get it right up front. The new CRM is going to require a couple tweaks to the code in addition to a config line change

* Maintainer needs to learn the custom layer you've built on top, whose documentation, googleability, and stack overflow support will be much less than the standard libraries.

To me, that's what I took away from the article's work horses. They focus
their efforts on moving the product forward and maintaining clean code.
Sometimes, that means forgoing the fancy engineering challenges.

I like this xkcd for trying to keep myself honest:
[http://xkcd.com/1205/](http://xkcd.com/1205/)

~~~
agentultra
You're absolutely right. It makes far more sense to make the tactical decision
to simply change the necessary code to work with the new CRM. I, and I suspect
most of us, make the very same decision every day. When your goal is to build
a product and ship then tactics, as in chess, will win you the game > 90% of
the time.

I apologize if my trivial example failed to illustrate my point for you.

My point is that part of being a good developer is learning how to avoid doing
the same task more than once. Tactical thinking inevitably leads to doing the
same things more than once. The best programmers I've had the opportunity to
work with rarely had to re-write anything they had to written. They had
internalized the paradigms, patterns, and practices to avoid writing code that
is brittle to changing requirements. This is what I mean when I say part of
being a good developer is learning to cultivate laziness.

Focus on the things that matter but learn to internalize ways to avoid making
work for yourself.

------
bgschiller
This guy keeps quoting his own tweets... from today.
[http://i.imgur.com/EePKQ.png](http://i.imgur.com/EePKQ.png)

~~~
petenixey
joshdance is right. I'm not undecided as whether it's obnoxious but I wanted
to see how it worked out as a way to encourage sharing. I'd not seen it done
before and so I wanted to experiment.

FWIW so far it's not massively affecting sharing about 5x'd the rate at which
people follow me on Twitter.

~~~
robbs
I thought the quotes were good and I don't mind that they are your own tweets.
I think you should remove the attribution and the date to make them more like
pull quotes. A discreet, low contrast link to the tweet would let people share
if they want.

------
raju
Great post. If you want a even _further_ expanded version of this I highly
recommend "Clean Code"[1] by Robert C. Martin, and I learned a few days ago
that there is a follow up book, "The Clean Coder"[2] which I am yet to read

[1] - [http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882)

[2] - [http://www.amazon.com/Clean-Coder-Conduct-Professional-
Progr...](http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers-
ebook/dp/B0050JLC9Y)

~~~
mcguire
About _The Clean Coder_ : [http://maniagnosis.crsr.net/2012/03/clean-
coder.html](http://maniagnosis.crsr.net/2012/03/clean-coder.html)

------
matwood
_You should aim for simplicity and over the years I have learned that
simplicity is far more easily attained by time spent working and refactoring
than hours of pure thought and “brilliance”._

This is where tests and egoless programming come into play. A lot of people
seem to get mad when someone touches their code. It is almost like they think
what they wrote is perfect, but the best programmers know that is never true.
Great code comes from writing and refactoring code for readability first, and
then refactoring for performance only after instrumentation.

------
Bahamut
I think one of the most important things is to learn for learning's sake - you
should want to improve yourself and expose yourself to new things, especially
if it makes you uncomfortable. The important thing is to challenge yourself
(near) continuously, since specific libraries can come and go, but patterns
can last longer.

------
AdrianRossouw
> You should aim for simplicity and over the years I have learned that
> simplicity is far more easily attained by time spent working and refactoring
> than hours of pure thought and “brilliance”.

Yup. It was Rich Hickey's presentation "Simple Made Easy" that finally allowed
me to put it into words. I got so frustrated about only having a 1 hour
presentation to link people to, that I ended up writing some notes to be able
to refer people to.

This is the money shot I think.

[http://daemon.co.za/2014/03/how-complexity-affects-
software/](http://daemon.co.za/2014/03/how-complexity-affects-software/)

This is also really relevant:

[http://thecodelesscode.com/case/108](http://thecodelesscode.com/case/108)

------
hawkharris
I appreciated some of the author's points, but his presentation was
egotistical. The pedantically phrased, autobiographical tweets didn't add much
to each section. It would have been more humble and interesting to include
quotes by other talented programmers.

~~~
gallamine
Perhaps you should find these interesting tweets and suggest them to the
author? It's easy to criticize. Hard to be constructive.

~~~
hawkharris
I'd love to! As a starting point, I'd recommend John Resig, Jeff Atwood and
Simon Peyton Jones. These are some of my favorite programmers who write about
being developers. I think they do a wonderful job of describing the process
and using metaphors to illustrate concepts.

There are hundreds of thousands of articles, books and sayings about code and
being a programmer. When an author thinks beyond himself (and doesn't quote
himself), he has exciting opportunities to draw from this pool of knowledge.

------
bubble_sort
This might be a little bit off-topic, but...

The example of a link shortener algorithm (what algorithm? generating new
unique url?) and a bubble sort (is it bubble sort the algorithm? really?) is
simply bad.

I would rather say that not the experience with specific problems makes
developers good, but rather the ability to tackle and solve new problems. And
I would say that a good developer given the task of writing a link shortener
should be able not only to do it but also do it right.

I do agree that being a good developer requires striking the right balance
between under- and over- -thinking, -complicating, -testing, ... In fewer
words: common sense.

But most of all (as also noted in the article) it requires doing things the
right way. The author might not believe it but there are tasks which require
not only good looking but also performant code. Some of us also actually have
to use some algorithms in our work. It all depends on the task.

------
chasing
Haven't we already had a great national discussion about the silliness of
using "rockstar," "ninja," "guru," etc. when describing someone^? They're so
vague...

I'm a rockstar Hacker News commenter ninja guru.

^ [Edit: Except in the case when someone is actually a rockstar, ninja, or
guru.]

------
AdrianRossouw
I agree with most of his points, and the parts we disagree on are more of a
philosophical difference.

I'm more of a sinatra-type than a rails-type, and I don't really trust
'frameworks' that try to do so many things for so many people. I like my
dependencies to have a much more clearly defined scope with fewer assumptions
made.

I also don't think loc is an indicator of simplicity. Removing duplication as
in his example, sure. But it being one line of code versus being 10 lines of
code because it relies on a specific set of side effects, that may drift over
time... not so much.

------
kordless
> Not only is their output erratic but their superiority is aspirational and
> infectious. Their arrogance bleeds toxically into the rest of the team.

The gift of brilliant insight does not necessarily imply a negative impact
elsewhere. I would agree this is probably an occasional side effect of having
The Gift, but I think making a blanket blaming statement about these types of
individuals is unfounded, and comes across as negative in and of itself.

That said, I think the rest of the post is absolutely bang on and
wholeheartedly agree with it.

------
junto
I'll leave this here from Joshua Bloch:

[http://www.youtube.com/watch?v=heh4OeB9A-c](http://www.youtube.com/watch?v=heh4OeB9A-c)

How To Design A Good API and Why it Matters

------
dorkitude
This post is great.

Couldn't agree more about the four hours per day piece. The best work I did in
my career as a dev was the year I worked 20 hour weeks.

------
yawz
In my opinion "depth vs. breadth" balance is very very tricky to get right. We
keep saying that a "fat T" is what we're going after. "Depth" is obvious but
"Breath" certainly helps in architecting, in seeing the bigger picture, in
being able to think out of a platform/language/framework's patterns.

------
zimbatm
tldr; things acquired by practice.

I wish we had a better way to measure and train specific parts of our brain.
For example how much capacity you have in your short-term memory. How fast
your analytical brain can combine things to find the best solution. How long
you can stay focused on a single task.

If we where doing some kind of sport, we would use weight lifts to train
specific muscles.

~~~
AdrianRossouw
Or you can just acknowledge that we are limited. all of us.

Once you realize that, aiming for simplicity first is the obvious choice.

[http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...](http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two)

------
read
I wish posts like this reduced their content to more concise descriptions so
more people would finish reading them.

------
ilcosrn
Off-topic, but the each page of the site (not just the one linked to) makes my
browser freeze for a couple of seconds and downloads ~3mb of crap. I don't
think the ninja rockstar guru programmers are the only ones capable of writing
a bubble sort and optimizing a page load.

------
rch
Why on earth is an article on creating great software, written by a CTO,
completely unreadable on a tablet (nexus 7)?

I'm tempted to turn this observation into broader philosophical diatribe, but
I'll refrain until I at least read the post somehow.

------
known
Every programming [https://en.m.wikipedia.org/wiki/Language-
agnostic](https://en.m.wikipedia.org/wiki/Language-agnostic) coder is a great
developer IMO.

------
GFK_of_xmaspast
"If there’s one thing that software developers care about, it’s becoming even
better software developers."

Observational evidence suggests otherwise.

------
JustinBrown
I actually googled "Ronseal Code" thinking it was an established convention
for writing code.

 _facepalm_

Any good links out there for clean code best-practices?

~~~
blevinstein
I did as well. To save everybody else from having to search, Ronseal is a
maker of wood stains, and their slogan is "Does exactly what it says on the
tin."

------
kenster07
This blog entry is not very generalizable. It implies a certain kind of
programming for a certain kind of business.

------
migidomingo
Definitely going to keep all this in mind as I start my developer career.
Thank you for this

------
CaRDiaK
Should be, "How to be a useful software developer".

------
kenrick95
Am I missing the point or is there really a mistake in this statement:
"Remember, there are only _two_ hard problems in computer science: cache
invalidation, naming, and off-by-one errors. " ?

~~~
simonw
It's a joke. Claiming two problems and listing three is an off-by-one error.

------
igvadaimon
As much as I like this post because of beeing 'working horse' myself, I still
believe that 'Rockstars' are very important when some brilliant solution is
really needed.

------
GarvielLoken
Worse is better.

------
weishigoname
lucky to know

------
anonymousdev
Oh, yes, it's great to be a workhorse developer. You don't get any
opportunities to use new technologies and improve your skills at work so you
have a choice: program at home after work and in weekends or become useless in
a few years and get out of the field or move into management if you're lucky.

It's really fun to make the first choice, because you either give up
socializing and live a hollow life focused exclusively on programming, or you
don't have time for physical exercises, cooking and eating real food(not junk)
and other human routines that keep you healthy and you die at 40.

But never worry, because right before you'll leave this world you'll be able
to say with immeasurable pride: "I've made someone else rich!".

Don't be stupid and care about interesting work and improving yourselves and
especially don't boast about it because you make the workhorses feel bad(and
FSM-forbid, even open their eyes). Shut up and keep your heads down because it
will all be over soon.

~~~
anonsdev
Lol, Yup. It's funny he used the term "workhorse". I remember what happened to
the workhorse in Animal Farm. A sucker is truly born every minute.

------
michaelochurch
I like most of what he has to say, but I have to attack this:

 _It signals loud and clear that if you’re smart enough you choose when you
work and what you work on._

What's so wrong with that?

In practice, I would prefer that a company use Github/Valve-style open
allocation, and extend that sort of freedom to the whole team. People who
can't justify their own salaries in an open-allocation environment (noting
that a typical engineer is worth 3-5x under closed allocation and 10-20x in
open allocation) are those you shouldn't be hiring anyway.

Often, brilliant, high-variance people are binary (or, at least, sporadic) in
output, not because they have an attitude problem, but because they're
neurologically built that way. Environments that favor (or, even, demand)
reliable mediocrity shut them down and lose the ability to hit the high notes.

The best way to work with such people is to give them an R&D environment where
they direct their own work and career. They know what they're doing, and they
make more of a profit with the hits than they lose on the misses. But I'm not
convinced that anyone who's smart enough to be a decent programmer _shouldn
't_ have the same freedom (open allocation).

~~~
e28eta
I'm coming from a large company mindset, but I disagree. We're working on
projects that are too big for a single person, no matter how brilliant.
Working well as a team is how we ship features.

Being predictable in our output is important to the business, because they
have plans for the project/feature that we'll work on next. There are
marketing and customer support teams working with us who also value our
ability to deliver what we've promised, and when. There are customers who need
features by a specific date.

I think the best engineers are the ones who improve the output of the entire
team. Just like a good manager can improve the productivity of their
engineers.

~~~
sheepmullet
A team can absorb the natural peaks and lulls that accompany high performance
far better than an individual can.

If you need everybody to be operating at 100% week on week in order to hit
your deliverables then you have over promised and introduced an incredible
amount of risk into your projects.

As a manager, if you care about the productivity and general well being of
your team then you will be promising a max of around 70% team effort. Managing
the expectations of other teams and departments is part of being a decent
manager.

Spend two weeks sharpening the ax and then another cutting down the tree? No,
the average company would rather you spend six, or even twelve, weeks chopping
away with your blunt ax.

