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?
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.
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.
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.
> 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).
"those who can, do; those who can't, teach"
More relevant is the low barrier to entry to blogging and Sturgeon's Law.
Dead Comment
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.
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.
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.
...if they spend all that type typing.
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.
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.
This means touch typists can think WHILE TYPING, giving them a distinct advantage.
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.
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.
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.
If you're payed by lines of code, than it's a different story, of course ;-)
I see fast typing not as a programming advantage, but as a thinking advantage.
If your typing skills are sub-par, that’s just one more stumbling block.
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.
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.
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.
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!).
I was lucky when I was a rookie to have a great mentor, to guide me into thinking about what I do and in challenging the practices and techniques of coding. I see a lot of developers these days without mentors, who look elsewhere for guidance and ideas.
And part of the problem with us (great and not great - it irrelevant IMHO) developers is we're all really good (or getting better at) at coding (it is what we love and do), but on average we're pretty awful at communicating. I learned much from the few I met who could communicate.
So I started to write. To learn how to communicate. And the best forum for that is the internet. Fast, clear, and often brutal feedback abounds. You either get better or you get out. Looking back, my early writing was terrible, you decide if it got better.
My goal was to share the nuggets I picked up over the years and share them, the good and bad. To be a virtual mentor, to pay back what I received. Some nuggets I believe are solid gold and I hope readers will find parts of them to help themselves grow, and some nuggets are radioactive and I hope readers will dodge these traps. I do not believe I am right all the time (and again, an internet discussion often reveals flaws in my knowledge and experience), all I wish to do is add value.
I do not tag myself as a "great" programmer, I trust I am not being too arrogant saying I am an "above average" programmer, this industry is huge and there is still much to learn for anyone to claim the title "master builder".