Ask HN: Are authors of “how to be great developer” blogs great developers?
Every time I am reading blog posts about "how to become a great developer", or "what´s the difference between a good and a great developer", I am marvelling the self-confidence of the author. Or better to say: I am wondering if I should have better self-confidence too?
During my 20 years of work experience as a developer, I´ve never felt that I am a great. Neither good. Maybe good enough, or good-ish. And it depends of many factors. First, I always know some guys, who are better than me. One is coding quicker, the other does not need so much googling or checking documentations during work, the next one has better code structure, and so on.
I always had/have multiple leveled lists in my head, what I need to improve. To write tests. To change Js to Ts. To practice quicker typing. To create better snippets. To learn better focusing. I could continue the list...
I don´t think I can tag myself as "great" until the list is done. Do these bloggers?
112 comments
[ 3.2 ms ] story [ 177 ms ] threadIf a recruiter / hiring manager sees a name attached to such blogs they naively automatically believe the candidate is “great”.
The artist definition of stealing (say for a painter) isn't literally moving your brush the exact same way that somebody else did. Stealing refers to the concepts. Someone could look at how, say, Vincent van Gogh painted and steal some of his techniques, his style. And combine that with their own experience, making something unique and beautiful.
In the context of computer programming, that definition of stealing refers to, again, concepts and techniques. Maybe I saw someone else write a piece of functionality in a certain way and thought it's neat, so I stole it. But I don't literally go through her code and copy-paste everything. I learn from her technique and adapt it to my own style, possibly making something new by combining it with what I already know.
I am unaware of a coaching analog as in pro sports - for development, one must do the work.
- Can x be done ?
- Yeah, it's like plumbing and data travel through pipes. Theoretically, anything is possible. But some plumbing require time/money/expertise we don't have.
I prefer this analogy to the first one I came up with at the beginning: we are basically just form builders automating if the form is filled correctly. Way less sexy than the plumbing analogy.
Not that there's a big difference between the two ;)
Never underestimate the power of marketing in our society. Fake till you make it is the motto.
We were all excited to talk to a him. He failed the interview, badly. He was really good at writing. Just not programming.
Most of the stuff I see is really just fortune cookie style bs that sounds useful but isn't. Blogs are actually a horrible source to learn from because they lack a systematized comprehensive framework for knowledge. I still love books or trying things out myself.
I don’t know who these people are that write self help content that is optimized for making it to the front page of HN but if I had to bet, I would bet that their core competency is blog writing and appealing to developers, not coding.
As for people who conscientiously study "great programmers" without being one of them ... I'm tempted to say (a) This kind of study can obviously be extremely interesting and worthwhile (e.g., Dava Sobel, Tracy Kidder, James Gleick, or John McPhee on scientists and engineers). But (b) It's still obviously going to mostly miss the real point for practitioners, as it isn't actual professional literature. Mostly.
Where did I read this approximate quote? "Earthlings will tell you that they are a race of inspired tool builders. Anyone else can plainly see they are really a race of passionate after-dinner speakers."
This specific one is something that baffles me. Development is all about thinking. You need to understand what you're building well in order to have any chance of making something that works and is bug-free. You need to spend time thinking of names that will make sense in 6 months. You need to organise things well. The actual act of typing things in is a tiny part of the whole process. If typing faster is improving your dev productivity then either you typed really slowly before, or you're not spending enough time thinking about what you're doing. I really don't understand why speed of text input is considered a useful metric on absolutely any level whatsoever. And I say that as someone who types quite fast and who knows their IDE well enough not to be reaching for a mouse every so often.
If you can do that faster, then perhaps you really can get gains. The typing speed is about iterating quicker to the best solution with draft code, not about literal speed of typing the best solution's code.
If you're payed by lines of code, than it's a different story, of course ;-)
Yes, thinking is more important than typing, but after you've had a thought, you need to see it "in writing" and execute it to evaluate it and see if it was a good thought after all.
Fast typists can go through many more iterations of that process in the same amount of time.
It has often been remarked by writers that writing is thinking. That you don't even know what you think until you write it. There is something very fundamental to the thought process that comes from actually recording the thoughts and seeing them "in print".
A good typist (which I'll call 100 WPM, a point beyond which I diminishing returns make further improvement less important) can do the writing-is-thinking process 4x more in the same amount of clock time as a 25 WPM typist.
I don't know that that is the only way. For instance, when I have thoughts, I often:
- repeat them in my head from various angles, while pacing around the room
- jot down some key words as anchors
- draw a diagram or two; sometimes to visualize relationships, sometimes to map out individual elements of the thought
- etc.
Then, when I start writing, even then I don't start with full sentences. I think about overall organization so might outline and iterate on that a few times so that I can refine. Only then do I start writing full sentences and edit, edit, etc.
...if they spend all that type typing.
My point is, being able to type 100 WPM without typos is surely nice, and so is e.g. having good vision (or vision at all, for that matter), but it's not strictly necessary and can be worked around. Although, of course, if you can come into possession of those qualities reasonably cheaply then sure, go on and obtain them.
Josh W Comeau has a fabulous article about hands-free coding that I think every developer should read: https://www.joshwcomeau.com/blog/hands-free-coding/
Everyone has a different optimum for sure.
But not all! If I am making an arcade game I might jot down the basic idea at most. I spend the majority of my time in a rapid-prototyping mode. I don’t write good code with all of my usual rigour; I write the first thing that could possibly work with the least amount of code possible. In this kind of prototyping mode I am constantly evaluating something you can’t really specify on paper: does it feel good, is it fun?
However I generally throw away that kind of code once I am done with it and rewrite it using my usual methods.
It is useful to practice “coding fast” for that reason. I had spent a good year or so practicing it as a skill. It can be useful. And being able to type fast can help reduce those iteration cycles. The goal is to get from idea to something that works and resembles the idea as quickly as possible.
So, while development is about thinking, delivery speed is always a factor, and they don't care if that speed comes from quick thinking, quick typing, quick replace all or quick copy-pasting.
People who can tear down and rebuild a piece of software quickly and fearlessly just try more things, just like mechanics who can rebuild an engine have usually have higher performance cars than the rest of us.
It is obviously not a substitute for thinking deeply, but it can be an aid to thinking deeply.
And outside of some rarified hyper-elite of Thompsons and Carmacks or something, thinking deeply is not a substitute for trying a lot of things.
Now time is finite, and learning to type properly or mastering your tools might not be the highest ROI at a given time, but this meme that “I can type faster than I think so I’m not bounded by typing” (which may not be your view, but you’ll agree is often said) is misleading bollocks that young hackers hear and often heed: which is setting them up to settle for less than their potential.
To use your mechanic analogy, the difference is the mechanic is confident in his abilities to tinker. The confidence is built on having a plan and some background knowledge. When he disassembles a carburetor he already knows the performance tweaks he’s going to make and how he’ll reassemble it. He doesn’t just start taking things apart with no plan, or start playing swapping on and off a handful of carburetors to see which performs best. He probably did his research and chose the carburetor/mod that was appropriate. It’s actually even more important with the tangible world because he has to plan and acquire the parts and tools before getting started or risk having a bricked vehicle for some period of time.
Non-mechanics know better than to tinker at all because they’ll likely break something they can’t figure out how to fix. So they might do low risk things like put high performance fluids in, or air filters, but they’ll never match up to the guys that have upgraded the mechanical systems.
Trying many things is usually far beyond an acceptable threshold of diminishing return. Premature optimization and such.
That’s not to say I am unfaltering, sometimes things don’t work out and I need to rethink it. But I don’t approach a problem with this approach of trying a bunch of stuff.
I see fast typing not as a programming advantage, but as a thinking advantage.
This means touch typists can think WHILE TYPING, giving them a distinct advantage.
If your typing skills are sub-par, that’s just one more stumbling block.
A tiny part of cutting actual code, and a big part of communicating and documenting that code to others. Even for a solo developer, you will always be communicating with your future self unless you are blessed with the kind of eidetic memory that can recall mindstates.
Software engineering today is both an intensely individualized experience (flow state is still A Thing for example) and a team sport heavily reliant upon lots of communicating between people in many different roles. Written communication is a big lever that propels you beyond verbal reach. I frequently see software developers who type slower than an average range of 40-60 wpm produce barely intelligible documentation, actively shirk ticket-based processes that involve much typing, and rarely if ever present their ideas to others in written form.
This is usually a hindrance to their careers. I keep hoping the parsimony of typing speed would act as a forcing function and be made up by concise, elegant written communication but alas, I have yet to run across such an example.
Are there executive coaches who are successful and yet give bad advice? Probably, but probably some excellent executive coaches learn to pattern match on problems and deliver a lot of value.
So, this is my long-winded way of saying advice can be valuable even if it comes from someone lacking the skill to use the advice. So, take advice with a grain of salt, realize much advice is autobiographical, but still, it can be valuable.
Part of what makes an executive coach any good is the relationships they develop so that they can offer relevant advice.
A lot of startup “advice” is like that. What people think matters probably didn’t, and what worked in one case probably won’t in yours. Context is king.
So if someone is writing from experience similar to yours, it might be pretty valuable, but it will never be as context specific as having a coach would be. Same for friends who you know are a step or two ahead of you and who have the time to give you advice - it sounds like that would be super valuable as well.
Magnus Carlsen has a coach. Serena Williams has a coach. To some extent you really don't care whether your coach is themselves independently capable, you only care that they make you better. it could be a rubber duck, it could be a talking tree, it could be a blog on "how to be great developer".
that said, yeah some of the advice out there is definitely bullshit, some other advice works for some but not others. you have to sift through all that/keep an open mind to just find the advice that works for you.
If I'm a CEO, I'm going to take advice from people who are successful CEO's, then people who have been CEO's longer than I have, then my peers, THEN maybe everyone else. MAYBE. But doubtful.
Most of these "executive coach" positions are cheerleaders, and for sure cheerleaders have a purpose, but advice aint it.
It's one thing if we're talking about an investor who has watched many CEO's over the years, it's another if it's a dude who is paid to give soundbites.
In my experience, even having someone to repeat things I already know every so often can be a helpful form of advice.
There’s a reason there are coaches as they can do the work full time and can offer better advice.
"those who can, do; those who can't, teach"
> Are good executive coaches good CEOs? No
No, but what do executive coaches do / contribute to a CEO's day-to-day & are they good at executing on that specific domain in their own lives/careers - yes.
In the same vein:
1. are development bloggers knowledgeable about the subjects they write about but less talented at executing on those topics efficiently.
OR
2. are development bloggers both knowledgeable and effective in their chosen subject & also excellent time managers (prolific in both blogging and developing)
OR
3. are they bad
I think all 3 of the above are possible (though the 2nd is extremely rare, & the 3rd is likely pretty common).
I cringe every time I see one of these posts. To be honest, I may even grudgingly bookmark it sometimes. Maybe I should be thinking more about ten ways to become a great developer, not just a good one!
But the truth is that I will probably never read it, and I certainly won't return to it or link it anywhere. I mean, the embarrassment! It's like telling your friend they should read the "10 Ways to Lose Weight Fast" articles in some grocery store checkout line magazine trash.
I'm an old-fashioned craftsperson that prefers either thoughtful and reasonable reflection about things that have worked out; or flat out angry rants about things that haven't.
And maybe this is because...real life works that way too? If you're talking to someone about your successes, you're probably not going "Here's 10 ways to become a great developer. Number 1..." – you're probably incorporating a lot of caveats into your suggestions, and emphasizing the specific context that they are made in. Meanwhile, about failures or things that didn't work out, you're probably going "Oh my god, I need a couple drinks before I can even begin to talk about how [terrible boss] single-handedly sunk our project".
In summary – You do you. But I prefer to read people who write like they talk.
To me, greatness comes from wise economic reasoning. Using TDD is an economic choice. Using a more sophisticated type system is an economic choice. Being quicker at typing is an economic choice — you can be the fastest typist in the world, but it's not much use if everything you type exists in a vacuum.
I think the software craftsmanship idea of greatness is to be disciplined enough to refactor every bit of code until it's squeaky "clean", whereas greatness in my mind is [at least partially] the ability to recognise when a part of a system is a bit of a mess, but functions correctly and reliably and is unlikely to ever need to be changed, rendering any effort expended in "refactoring" to be a waste.
Anyway, rant over. And of course, you don't _have_ to listen to me, or care about my rants, just like I don't have to listen to you complaining that I'm "offended".
he/she has been a thing since at least the 90's.
More relevant is the low barrier to entry to blogging and Sturgeon's Law.
The real trick is to identify those things that will have a beneficial effect. In my opinion, being able to write tests well is an essential skill for any programmer.
Personally I think switching from Js to Ts won't have a big impact on your ability to program, but learning a new paradigm of programming will have big impact.
Very rarely have I seen a programmer where their typing speed has been their limiting factor - I have seen programmers type a rat's nest of code very quickly though :)
https://news.ycombinator.com/item?id=27468654
Someone who ships practices their craft. Someone who ships learns seeks out how to get better. Someone who ships discerns between the new shiny and actually useful.
Mediocre coders who write well - and ship! - may be more useful than an ace developer who can't lay out a plan. It depends on the task at hand. But it's the actual getting something made.
There are good developers out there writing blogs. You can tell how good they are by how intelligent and insightful their thoughts are. Most coding blogs (99% of what you find on Google) aren't those people; they range from "unhelpful" to "criminally bad, you just learned to code last month and your bootcamp requires you to keep writing blog posts and pretending to know things until you get a job" (a real thing!).