Hacker News Reader

> If you were really "better than almost everybody else" you'd be hired to work on hard problems that even someone actually better than almost everybody else would find challenging.

That's assuming a lot. It's assuming that great programmers also make great career decisions. It's assuming that well funded companies or startups necessarily have the most difficult tech problems. It's assuming that the people who hired you to do really tough problems don't also have a huge list of "mundane" problems to solve as well.

I've had some really interesting problems and challenges to solve during my career. But every role also has a lot of boilerplate. I've found that what has really made me valuable isn't just my ability to solve the challenging problems, but also being able to see a project from conception to completion, even when you have to do the tedious and uninteresting tasks.

If there are a bunch of mundane tasks, the responsible thing to do is to delegate those tasks to a junior developer:

1. I'm happy because I don't have to do mundane tasks.

2. The junior developer is happy because those tasks aren't mundane for them.

3. Management is happy because the junior developer gets paid half as much as I do.

I disagree with this approach.

My policy as a tech lead (and then manager) was to spread the mundane tasks across the team equally. This let everyone experience the pain points and usually led to faster elimination of technical debt, since the senior developers would see patterns in the pain and find ways to address it. (Junior engineers often don't have the experience to recognize bad patterns or bad smells and would happily plow through a bunch of mundane tasks that could be done better with a higher level solution.)

It helped that we had a Tech Debt Week every 8-10 weeks where we took a week to fix problematic code and harden our deployment and automation processes. It was hugely popular with the engineers, we gave out trophies for the best fixes based on team vote.

The "share the love, share the hate" approach also meant that new junior developers were given challenging tasks as soon as they joined the team (and were paired with a senior developer for support). If they excelled, we gave them even harder things to work on. If they struggled, we found easier projects for them to work on and coached them through it so they didn't feel bad about their struggle--we always said it was better to try challenging problems and fail than attempt something safe and easy. Either way, we started new team members with the hard stuff instead of ramping them up slowly on the easy stuff.

The same policy applied to interns. They got challenging and impactful projects, no busy work or work the team didn't want to do. This meant we had a huge return rate on our interns and most of them joined our team when they came to work full-time.

No, the responsible thing to do is to build tools that do them for you, and then other tools that check they're being done correctly.

Failing that: often, products are made or broken on the ability to get the mundane parts done efficiently and properly. If anything, this means those parts deserve the attention of a more experienced engineer; otherwise, you'll end up rewriting them anyways, or at the very least spending more time in supervision than you would have to just write the damn thing. (And if you don't spend that time in supervision, well, you probably shouldn't be in a position to mentor anyone.)

I couldn't agree more with GP: good programmers are the ones who bring the same standard of work to the mundane tasks as to the fiendishly challenging ones. I'd go further: the best programmers are those who look at the supposedly challenging tasks and ask: "Why are we solving this problem? Is there a mundane problem we can substitute to achieve the same result?"

A good programmer produces good code. The motivation or their personal feelings is absolutely irrelevant. Your comparison does not makes sense. There's no reason on his text to assume he's not a good programmer. We can say, that at least to his eyes, he's a very good programer, and that's all we know. The rest your saying comes from personal bias and generalizations.

Lastly, the programmer can make his decisions on financial grounds instead of "difficult problems". The most difficult problems are on academia, but not everybody goes to academia because the pay is low and the job opportunities are few.

All you're doing is pointing out a morality conflict, which really isn't an argument. A good person is one who the solves problems that need to be solved. This person said they don't care what problems they solve, so long as they prop up their own ego. That's hardly a position that the rest of us need to consider 'good.'

You could just as well be saying that someone who programs to hurt people and commit crimes can be a good programmer. They may be skilled, but 'good' is a more general term.

I think it's pretty clear that the quoted person means "skilled" when he says "very good". Good not only mean "what is morally right" but also "having a high standard". He didn't said a "good person", he said a "good programmer", it usully implies a "skilled programmer", not an "morally sound programmer". The same way a "good restaurant" don't usually imply that all their food is fair trade organic ethically sourced, but that the food is prepared with high quality.

I've been called "mastery-motivated" which means that I like to be able to accomplish what I want, when I want, better, faster, more efficiently, and more flexibly than anyone that I'm aware of. It honestly means that I hate introducing new things for novelties sake, and I would be happiest if the field never moved at all and I could get the job done in five minutes using something I wrote three years ago. Of course, it also means that if something five minutes old does everything in a better way than my old stuff, I need to know it now.

That's certainly not the same as passion for my work. It's more passion to get home and passion not to be a burden on my co-workers but a boon. Work is a place I go to make someone else money in exchange for as much as I can extort them into paying me.

summary: I agree 100% with Jack, but 0% with you, so I'm confused by your first line.

I spotted the same comment and chuckled.

Programming is never boring because it is inherently tied to the challenge itself: programming occurs at the very bleeding edge of new research and new challenges because. Everything that has already been solved for good has been implemented, so reuse or rewriting it is trivial. Programming is about turning an open question into an automated answer which moves the bleeding edge further each time.

In my experience, programming only gets more and more interesting because as we crack the challenges they level up all the time. I'm working on way more interesting, harder, and complex problems than what I was 10-15 years ago. The problem domain levels up, too.

>No, you're not a good programmer because there's no challenge any more. You're a bad programmer because you've lost sight of the context of your work.

I think you're being more than a little naive here. A very large portion of the software work that actually pays is, on a personal level, total BS. It's about helping a business do something boring in a much more efficient way than ever before. Or providing a service electronically that used to be done via snail mail. Or providing a way for bored people to make their commute bearable.

You can try and dismiss this as "turd polishing" but the reality is that if it was easy anyone would be doing it. I'm never going to be passionate about the product my company makes, but I still have the self respect to not produce terrible code that burdens my coworkers (and ultimately the customers).

In short: it isn't all about robots, spaceships and self-driving cars and stuff for most programmers. But we still gotta get to work.

Being altruistic and/or ambitious is not a prerequisite to being technically better than other people, gaining skills can just be done for personal pleasure.

My strengthsFinder assessment lists Life Long Learner as one of my top 5 strengths. And that is so true. I love learning new things to the point that if I'm not careful it can be dysfunctional. It is not so much about learning something deep as it is about learning that something is possible and whether it is easy or hard.

Being that my job is to develop and manager a small team of developers I can easily satisfy my quest to learn. I just have to be careful to not then burden my team with new technology for the sake of technology since whatever tools and tech we use has to be supported by a very small team long after I am gone.

On the plus side if I do this well then I uncover technology or tools once in awhile that help the team achieve our goals faster, better, cheaper.

Yup, I think is very common, I'm in a similar position and feel the same way. Partly it feels like a game; filling in holes in knowledge is like locating pieces that fill gaps in a jigsaw. And partly it feels like a scrabble up a hill - the more you learn, the more you realise how little you know, so you try to grab more and more knowledge.

And it does lead very often to bad programming, I appreciate the GP point - reinventing wheels, NIH syndrome, overuse of clever techniques etc., but that's not necessarily the case; a big chunk of the knowledge you grasp is [or should be] best practices, testing, clean code etc v0v

All good points. I'm not a NIH person so that has never been a problem. But I can be distracted by personal projects and work projects that are optional.

I have been focusing my learn at work activity on: - learning the languages I use better - learn the tools better (IDE, etc.) - and improving our software development processes

We have a long way to go on software development processes (best practices) because we are 100% self taught team that covers a diverse but not uncommon set of technologies (linux, apache httpd, javascript, jquery, angular, sass, java, bash, php, etc.) and we are always slammed with priorities for senior management of the university.

I do love filling in the gaps with learning. Sometimes I find something I learned a long time ago causes something else to fall in place and I think to myself "that is why I needed to learn that". Maybe a bit of serendipity.

Or he could be someone who has kids who he needs to feed, clothe and house. :-)

At this point, I'll be happy when I get a job.