Ask HN: Are authors of “how to be great developer” blogs great developers? | Hacker News Reader

Ask HN: Are authors of “how to be great developer” blogs great developers?

88 pointsvpaulus109 comments

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?

View on HN

Some CEO's have executive coaches that they pay lots of money to. Are good executive coaches good CEOs? No, they are good executive coaches, but that's ok, because that is their job.

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.

Importantly: a lot of advice is contextual. If you lack the context, then it’s just noise.

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.

Context is king. I like that.

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.

this is what i came here to say (take with a grain of salt of course, because i also do developer advice).

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.

Slight variation on this one: You can spot what great developers are doing even if you're not one of them. I may at the same time not think of some situation when writing code, but also notice that someone did catch it, that it's important and non-obvious, and that the comment they wrote about it is very thoughtful.

You can spot SOME things great developers do, others you'll think are terrible ideas because you yourself are not a great developer.

"Be wary of advice from people who suffer no consequences if that advice is wrong" - someone

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 any field there are obvious mistakes that all the beginners make and are well understood. The message that beginners need to hear - "this is a common mistake, don't do it!" - can be farmed out to an adviser who doesn't understand the field.

In my experience, even having someone to repeat things I already know every so often can be a helpful form of advice.

That's a reasonable caveat but we both know that isn't what these advisors are advertising.

I read the advice you quoted in Skin in the Game by Nassim Taleb.

What consequences does a CEO suffer if the advice that he gives other CEO's turns out to be wrong?

“Take the advice of other successful CEOs” … are those other CEOs working for you day to day? How are they giving advice tailored to your company’s needs that go beyond the typical “invest in your employees” line that everyone knows.

There’s a reason there are coaches as they can do the work full time and can offer better advice.

Or:

"those who can, do; those who can't, teach"

There's two sides to this though:

> 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.

2. are development bloggers both knowledgeable and effective in their chosen subject & also excellent time managers (prolific in both blogging and developing)

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).

My take: I like the Bruce Lee quote:

   I fear not the man who has practiced 10,000 kicks once, 
   but I fear the man who has practiced one kick 10,000 times.

The people who blog about being great developers are largely bordering on snakeoil salesmen/women. I think the great devs are too busy writing code.

I'd elaborate and endorse this view, but I'm too busy writing code.

As a mediocre developer, I'll gladly endorse this view.

This gave me a good chuckle.

Mostly https://tenor.com/view/aliens-newt-mostly-gif-25791528

I write in order to understand and solidify a concept in my mind and so that I don’t have to remember it next time I face a similar problem. I used to do so publicly but I mostly write privately now.

Depends on your criteria. If you are interested in the best solo developer it's probably true. But in software engineering the hardest part is working in teams. Building a large scale system too large to fit in anyone's head while still maintaining a reasonable degree of modularity and cohesion is very difficult and requires a degree of verbal and written communication that could translate very well to blogging.

More relevant is the low barrier to entry to blogging and Sturgeon's Law.

To practice quicker typing.

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.

I guess one aspect here - and it will depend on the individual obviously - is thinking through solutions by coding them. As opposed to doodling or whiteboarding, for instance.

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.

The only argument why fast typing could be important that comes to my mind is that you're less distracted (from thinking) if you can type fast without looking at your keyboard.

If you're payed by lines of code, than it's a different story, of course ;-)

As someone who types quite fast, if you haven't watched someone who types 20-30 wpm, then you probably haven't seen what a hindrance it can be.

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.

> 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.

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.

"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."

...if they spend all that type typing.

You see, if you type faster that you think that means that you're typing out things nobody's thought about — which is what it means to be a genius.

I've used to work with a guy who had... dyslexia, I think? Dysgraphia? Basically, he simply couldn't type without typos, although he seemed to do fine with reading. Well, he relied heavily on copy-pasting code snippets around, those sometimes being as small as a single keyword. Quite a sight to see, to be fair.

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.

Absolutely.

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.

I type with 2 or 3 fingers and I usually have to look at my keyboard... but it doesn't slow my code, it's Intellisense (Visual Studio auto complete) that does the typing for me.

As an avid writer/thinker I do tend to write a lot of software on paper first.

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.

As a junior developer I once had a pair programming session with a more senior developer who was baffled that I don't rely on VS Code features like replace all, I don't copy-paste code from other sections of the application that roughly resemble the feature I'm building, etc.

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.

But copy & pasting or using IDE features is more about consistency than speed. I.e. making sure you really did replace _all_

Typing well and being fast with the tools changes the code you end up with, not when you end up with the code. It drives the “activation energy” for trying a different approach, or fixing some structural flaw that’s on the bubble of being “good enough”.

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.

Maybe just different styles and approaches and typing speed is a easy, obviously, and measurable metric to focus on but this sounds like brute force problem solving. I tend to prefer to build a mental model/plan such that once I start writing the first draft is probably within 90% of the final, some iteration taking place on that last 10%. But I don’t write and delete large swaths of code. This sounds like real time refactoring/lack of planning and completely erases any gain I’d get from being able to type twice as fast (I’m probably middle/average speed).

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.

Sometimes times the only way to know which way is best is to try all the options.

While true depending what’s meant by the “best” way. I feel like I can mostly do this mentally without typing it out. I utilize my experience instead of a try and see approach. I know what not to try.

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.

For complex programs, you won't be able to keep all relevant aspects in short term memory. So the only option is to quickly write down everything.

I see fast typing not as a programming advantage, but as a thinking advantage.

When someone looks at the keyboard they're not thinking about the problem, they're thinking about typing. They're engaging parts of their brain to do so that touch typists do not.

This means touch typists can think WHILE TYPING, giving them a distinct advantage.

Good engineers write not just code, but good documentation and technical write-ups explaining decisions and the pros/cons of different choices (RFCs).

If your typing skills are sub-par, that’s just one more stumbling block.

> The actual act of typing things in is a tiny* part of the whole process.*

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.

There appears to be a formula to make it to the front page of HN. I haven’t entirely nailed down the specifics, but it’s nearly exclusively self-congratulatory drivel about how to adapt to the world/industry as an individual that’s Way Smarter Than Everybody Else.

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 think it's up to you to determine what you want to do, but I see most of the "the real difference between great and good {developers, managers}" sort of posts as overconfident and self-promotional. In our (America-centric tech) culture that's soaked in cheerleading and self-promotion, this might work for a lot of people. It doesn't work for me.

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.

It's honestly like 99% marketing and 1% skill. The other day I saw a Vlog from a YouTube developer advocating to avoid else statements completely because it leads to 'cleaner code.' It will 'force you to make all your intentions clear.' But it also means duplicating a negative expression for every boolean that is to have an else which is tedious, unnecessary, and just ridiculous. This is the kind of garbage being given out for advice.

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.

No, god.

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 occasionally write one of these blogs. I have been programming for 32 years and have achieved more success by doing it than I could have expected. I've learned a few things here and there. Some days I write amazingly great code, most days, vomitus shit code. All this experience just means I recognize better which is which. But I keep learning, every day.

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".

All the programmers I consider to be role models don't have time or care to blog, so I would support the hypothesis that they are mostly not great developers and only trying to sell you something. I personally never had much of a doubt.

The old household names (like Fowler) that speak at conferences or write books I trust far more than your average blogger though.

Development is a form of craftsmanship. If I was commissioning an artist I would look at their portfolio - not how they "talk about art". So the question is, have the folks blogging actually produced something well known? If yes, I'm happy to take their blog seriously.

You don't have to have been a great racehorse to be a good jockey. A lot of advice about some ostensible topic is actually advice about how to organize your life, good habits, that kind of thing.

I think this is great insight into the culture. We all really want to be that "talented" person's seemingly-shallow-thinking-but-in-the-end-incredibly-insightful boss.

Let's face it, developers are like plumbers. What we do is not meant to be on show. Being a great developer is like being a great plumber.

Agree, even though many consider coding is a craftsmanship, it's not supposed to be seen as art

Haha, I count this as a very good parallelism, as I had close connection to construction workers. Seweage pipelining can be done by multiple ways. There are ones which will clog in shorter or longer time. There are ones which made up by more parts than really needed. And there are perfectly goods which also obey all standards. Will the third one write a blog as "how to great plumbing"? Or just will say: "I know plumbing"?

or "Im busy plumbing if I am not wasting time on Plumber News"

As a data engineer I often describe my job as a glorified plumber.

I am using the plumber/plumbing analogy all the time.

- 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.

As a project manager (whatever it means) in a big organization with 1000 apps, i often describe myself as a plumber at least the 1st sentence: what do you do? IT plumber in a big corpo

Being able to synthesize information, and write, is a talent that is completely different from being a developer.

The world is full of examples of fantastic developers that cannot show others what to do.

I have been a coach, but not an elite Olympic athlete.

Look at all the great sports coaches - they were not Superbowl or World Series winners.

I've always hated the saying, "Those who can, do. Those who can't, teach." Teaching is a skill. Great teachers have great teaching skills. We've all had crap teachers, we've all had great teachers.

If I read 500 books about developers, and talk to 500 great developers, and I have enough knowledge about development, and can then put together an enjoyable read that imparts great knowledge that is correct, even if I can't develop myself, that's fine, if the information is actually correct.

To your point of working 20 years as a developer: I was in a sport a long time and pretty much sucked at it, trust me, so many people were way better. I was better than 99.9% of the general population, but of those elite in the sport....no. But I REALLY enjoyed being a coach, it was great. And, the people that I taught got perfectly good information from me.

But, it wasn't like I was Vince Lombardi or Bill Belichick. Nobody knows me from my coaching, except those that I coached. But, if you are getting paid, why does it matter? Good enough is good enough.

I think you are worrying about things too much. What I know about you is that you are better than 99.999999% of the world's population at what you do. If you are not part of the elite .0001%, oh well, nobody is, except that .0001%. Not even worth bothering yourself about.

I accept that there are some people who are unusually great at coding, who are also able and willing to explain how they do what they do. What I'm skeptical about is how many of them are writing these things ... vs how many of the authors are more like me (aspirational, more or less mean well, and like to hear myself talk).

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."

Probably to the same extent as the writers of 'How to become really rich, really easily' courses are really rich. Which always makes me wonder why they need to try and earn money selling self-help courses.

You can’t sell shovels in a gold rush unless people think you’re a prospector.

Whenever I read the actual article, it's pretty clear from both the prose and the actual content that they're either just regurgitating the stuff they heard from Uncle Bob, or they're just making up what they think sounds like a good engineer to them, without ever checking if their headcanon lines up with reality.

Not that there's a big difference between the two ;)

All of the people that I consider exceptional developers don't have an active blog.

But I can name plenty of mediocre developers who wrote a book...

What about a guy like DHH or Yehuda Katz?

I would consider DHH an excellent leader and I enjoyed reading his books, but I didn't hear anything particularly noteworthy of his programming skills.

I haven't heard of Yehuda Katz before, so no idea there.

Consider this set of ideas -- made up right now, on the spot -- as potential answers to the question "How to be a great developer?":

-- Practice code

-- Read code

-- Read ideas about what makes good code

-- Write about what makes code good, try to practice the principles

-- Try different languages, especially ones that are different from the ones you first learn (i.e. functional if you learned procedural, object oriented, and of course Prolog)

What is wrong with these suggestions? Do you believe they will make you a great programmer?

Well, yes, these are great suggestions but the problem is:

1. They are self evident

2. They take a lot of time

What is missing is the tradeoff. If you just tell people all the ways to practice, then you aren't really giving them information. Its not false, and I don't have to be a great programmer to render this simple advice.

I'm always skeptical of listicles... I assume they're good Authors who happen to be developers, not necessarily great ones. I think a good analogy is great law professors who are not necessarily great lawyers in the field - it's a domain thing.

We all think there's things we need to work on to be better programmers, it doesn't mean that we're not already great programmers.

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 :)

There are some people who are truly talented like Kent C. Dodds, but we also have a lot of people in tech whom we have made famous for next to nothing, a few that comes to mind: Techlead, Ben Awad, and the likes

I feel most confident programmers have probably only worked in well architected and well resourced projects, or more likely small projects with clear requirements and easy implementations. The big systems with under resourced teams and loads of tech debt are needed to make any dev doubt themselves.

On the subject of who is "best", everyone has a different criteria. Someone who knocks out lots of websites has different skills to someone who's tuning old systems, vs CS researcher, vs startup founder who makes $$$. Which one is best?

Of course they’re not. They’re selling a shallow self-help brand, disguised as greybeard developer insights.

It’s easy to find examples of actual great developers & read about their work.

Related comment about thought leaders:

https://news.ycombinator.com/item?id=27468654

It doesn't necessarily take a great developer to identify the characteristics of great developers. Does a football coach need to be a great football player?

This obsession with being "great" is unhelpful. The only question that matters is: Do you ship?

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.

What is a great developer? Are they people who single-handedly deliver memorable products of such scale or in such short times as to be amazing? Are they people who raise the level of their team to significantly higher levels? Either way, such people are known by production -> reputation. Once there, some write about the path (bell labs).

I am unaware of a coaching analog as in pro sports - for development, one must do the work.

Not to forget almost all of these blogs are attempts at self promotion and establishing one as thought leaders or post the link in their resumes for help with their own careers. Any leader who has spent some time in the industry should recognize this and protect their organizations from blindly wasting time and effort to walk down every latest and greatest thing that is vended by these “thought leaders”.

Somewhere there's a Venn diagram that shows a small circle of great developers, and a large circle of people who are blogging about how to be great. The two circles barely overlap. That said, I've seen many a coach who was not a great player produce great players... and many a professor who toils in anonymity produce students that become experts in their fields...

I'd say it's a lot easier to write articles on how to become a great developer than it is to be a great developer.

Another way to perceive it is that a great developer is one who has consistently contributed to great projects. Any generalist who shows up to their job every day could potentially achieve that. There is a large overlap between being a gifted engineer and being hard to work with, so the opportunities will be there.

I’d say the vast majority are for SEO reasons and the “great” developers can easily find work by professional reputation in their networks.

If a recruiter / hiring manager sees a name attached to such blogs they naively automatically believe the candidate is “great”.

Check out this summary of a peer-reviewed paper titled “What Distinguishes Great Software Engineers?”

https://abinoda.substack.com/p/great-engineers

IMO it's essentially marketing themselves. There can be good lessons there and they can be worth reading, but it's important to remember that the post itself is often there to "show expertise" rather than inform.

Why do you care?

I guess you must be writing this to get some comfort that other people are also struggling with self-doubt as developers? Yes, definitely. Don’t worry about the bloggers. Take what ideas seem useful and move on.

Maybe I am one of those writers, but I don't think you and I have the same definitions of greatness in this context.

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.

Hmm do great developers really even think or worry about being a great developer?

Everyone is on their own path and has their own strengths, there’s not much point in comparing yourself to others (unless you want to be unhappy)

I remember there was some youtube series that showed famous developers (from famous software) develop - actually showing their process and IDE screen as they work.

Can't recall what it was called though.

Interviewed a guy that wrote a JavaScript book. Don’t recall which one.

We were all excited to talk to a him. He failed the interview, badly. He was really good at writing. Just not programming.

Are you confident your interview is capable of accurately assessing a programer's ability.

Yes.

In my eyes, if you’re self aware enough to realize that there’s always something to learn and improve, you’re already better than 90% of your peers.

What are the economics here? Can one make more money as a developer or a blogger? Talent tends to follow money, so that should tell us something.

Most people are average-ish by definition (either somewhat below or somewhat above average), chances are you are average-ish too.

This makes sense. Maybe over time, the community average will move up according to some arbitrary metric. But the benchmark of "being average" means it's relative to the community.

"I'm not a great developer, I'm a good developer with great habits." -- Kent Beck

There are very few which are great in the level of carmak . All the other just poor click bait

   Those who can, do
   Those who can not, teach
   Those who can not teach, manage
   Those who can not manage, teach management
   and those who can not teach management, manage teachers

Like artists, good developers copy from StackOverflow (and give credit or references) and great developers steal from StackOverflow using Copilot (and claim it as their own).

Some of the most fun programming starts at the point where SO becomes useless. I’m not sure where Copilot pans out, but I suspect it happens there as well.

This is a very bad take IMO.

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.

https://xkcd.com/1053/

The truth is that "great" is subjective, and any given developer blogger could be a proper resource for any number of people depending on where they are in their journey.

If it were otherwise you could say to any aspiring developer, "Read The Art of Programming by Knuth and just derive everything else from first principles"

A truly mediocre programmer could teach a great deal to a beginner. A master could skirt over various complexities and disappear up their own butt in abstractions.

great developers are busy making $$$$$ they are not trying to persuade others they are great developers by writing blogs.

Trying to persuade others you're a great developer by writing blogs is how some people I know got cushy positions as CTOs making obscene amounts of money and equity.

Never underestimate the power of marketing in our society. Fake till you make it is the motto.

Reply on news.ycombinator.com