Hacker News Reader

Comment by JimmieMcnulty | Hacker News Reader

The problem is that “just coding” isn’t all that valuable, relatively speaking.

College grads can do it barely, and 5 years in they’re fine. What do you do with the rest of the people who, 10 years after that, want to do the same things but get paid 50%+ more?

“Virtuoso” coders aren’t worth much (relatively), because it’s not that rare, and honestly bugs aren’t really a big deal. Heck, you can write some pretty terrible code, and as long as it’s not some specific flavors of bad, your company will be totally okay for a very long time.

View on HN

It depends what you are building. Make a simple CRUD, sure any code-monkey can eventually build one from ground-up even. Move on to something more arcane and complicated, you really need a specialist with eye towards simplicity and maintainability rather than having bunch mediocre coders building some buggy monstrosity. That's how you end up with these bloated and inefficient systems that go millions over-budget.

Single virtuoso coder - or just a coder who just actually puts the effort to keep the mess contained - can be the glue that keeps the project actually usable and who in-turn educates others to be better programmers.

They may not produce +50% more code than their less senior peers but the code that's in total written will be of much higher quality. That's how I see it. It's like having a great musician in a band - everyone will strive to play better to meet their standard.

+1. Coding is such a wide field - and while there are some areas that one can probably master in a short time (CRUD apps as you mention, which are rather repetitive), there's also a lot of other areas where even people with decades of experience can still learn.

I've worked a lot on networking stacks, protocols and servers, and it found to be extremely specialized. It's unlikely one can an engineer with 5 years of "generic coding experience" which would be immediately productive in the field. I assume the same goes for implementing operating systems, databases, compilers (like LLVM), graphics engines, etc. Sure, a junior engineer that is new to the field could probably also implement something - but it would likely end up less reliable and less extensible and maintainable than if someone who has worked on a similar system before.

At that level it's however also all a bit of a mix between coding/implementation and design. While there's no real "system design" since the piece of software might just be a single component, there are still the usual design questions involved like "how does this component fit into the environment, like the APIs the operating system offers", "how will it be used", "what operational requirements need to be fulfilled", and "how can it be made to be as efficient as possible". Having a good amount of experience on how components will work together will be very helpful.

That's not really virtuoso, that's just what you get a while (5-10 years, sometimes less) after starting your coding career.

My larger point is that they're not worth as much as the coder who can also project manage/lead/mentor/etc, because the latter coder can both be a "virtuoso" (or like 95% of one) and also make the people around them better, and that's substantially more valuable.

The thing folks who "just want to code" don't realize is that their "value above replacement" is never going to be high enough to justify the desired pay increase over time that most folks expect as they advance in their careers.

That said, it's probably more fine if you want to be 10+ years into your career and accept the pay comparable to those more junior coders. Some people do get this by negotiating fewer hours, for example.

And not for nothing, but leading/mentoring is highly achievable for any "virtuoso" coder; not wanting to help others and pitch in on design is a personal choice, as most "virtuoso" coders would probably be great at both if they put in the effort. It just means holding meetings more and coding less, which is outside of their comfort zone and therefore "scary" in some sense.

They could be doing so many other great things, I wish they would please try to get over their insecurities and fears! I will help, as that's my job because I did get over those things and transition into this role from a coding role.

Well I would disagree that anyone would get to that level. Some folk just never seem to learn how to properly build and maintain a software project. Sure though I agree that any virtuoso coder should branch out to mentoring and architecting as that's basically expected of them having the experience.

Yet I don't know hour-wise how much they'd have to put in having meetings if they already kinda know how to build the system. I don't think that would necessarily be scary to them, just annoying if they had to be constantly distracted by having to mull over details that aren't that important.

To me a virtuoso is the consultant who knows how to build all parts of the project who is not there to lead the team but will help out anyone in the project - and will take care of it being built properly.

… that’s literally what all the meetings are for, to take care of building the project properly, because you know how to build all of the parts of the product.

There is no level of skill at which anyone will ever just be able to do an entire project on their own; no matter how good you are, you’re always going to be better with others.

I agree, but ability to code well may help you to guide others. In case that you can code, you may create diagrams as well. You can also create presentations from code. You can point out what is important to solve given problem and use code as example, show some diagrams that describes given process, describe facts and knowledge that you used to solve this problem.

I still like to code, but today I do it mostly in form of some kind of presentations, this might be informal presentation for developers/operations for given use case, this might be presentation describing deployment/infrastructure/architecture, but in general purpose is to guide less experienced engineers to use efficient methods of solving problems instead of just smashing code together.

Based on my experience, communication barriers are biggest issue in big corporations and it's crucial to communicate your knowledge to others in approachable way, even if solution is technically not optimal. It's described so it can be improved later. However sophisticated solution that is not documented, may technically work better, but it's maintenance nightmare.

Has anyone ever liked situation, where you get alert about production incident and you have no idea how to fix it, because you don't understand what happened? This is a people problem, not technical problem, because you cannot understand everything and either someone will explain system to you or you may have no idea how to react. People that understand people problems will ensure that there's always proper documentation and processes to follow, so no-one is stuck. Technical master will create greatest technical solution, but eventually systems fail and that's where the problem begins, if others don't really understand them.

> Heck, you can write some pretty terrible code, and as long as it’s not some specific flavors of bad, your company will be totally okay for a very long time.

That's why software is a shithole compared with less abstract machines.

As software is eating the world this becomes a greater problem with every year passing. And the even greater problem behind that is that we won't be able to fix the already created mess, ever. The current shithole is almost unfixable as it would require decades of fundamental clean up…

Exactly the above cited attitude brought us into this situation.

It's like all doctors would says: "Well, up to 30% of our patients die while treated, but who cares? You can't get better medical care anyway anywhere because just nobody cares—and it would be actually to expansive to put more caution into this." ¯\_(ツ)_/¯

If that would be the common sense among almost all doctors the patients that make it would be "totally okay" with that likely too; as they would not even know that their chances with most treatments could be much better, if only the doctors would be more willing, and of course capable, in the first place.

The "code is good enough if it works", and "bugs in software are god given" attitude is imho the root cause all evil in software development.

As long as this does not change broadly humanity is doomed to have only bug ridden security nightmares, that barely work, instead of proper "virtual tools". It's even a wonder that actually anything computer related works despite this "who cares" attitude among the majority of coders.

Might be off topic, but are you saying doctors aren't like how you described?

Because while modern medicine has advanced a lot, AFAIK there are still some cases where the quality of medical treatment is exactly how you described. For one, there aren't really any processes in place to ensure doctors actually keep themselves up to date with the latest medical knowledge, so the doctor you see might be say 20 years out of date. And yes, for this example, it would be expensive to fix this, say you enforce a rule that 20% of the doctor's time must be spent on something other than treating patients or revenue generation. So nobody's gonna do this.

At least software doesn't often lead to deaths. At least not directly.

virtuoso? i'd settle for ability to think and learn. i have been surprised by someone hired as senior software engineer - two levels above me - struggle to understand simple multithreading and synchronization concepts even when provided with an article that gives comprehensive overview of the OS's scheduler.

Reply on news.ycombinator.com