Hacker News Reader

> I would expect from developers is to be professionals and strive to the high technical quality of implementation, even if they don't believe in the usefulness of the project.

And these are very reasonable requirements.

As programmer, what I want from leadership is product vision, basic knowledge of software quality economics, lack of scope creep, technical debt control, good people management, and respecting the law. More often than not, you get zero out of these six.

> As programmer, what I want from leadership is product vision, basic knowledge of software quality economics, lack of scope creep, technical debt control, good people management, and respecting the law. More often than not, you get zero out of these six.

These are all great things to ask for. I'd also be tempted to add "Ethical decision making and respect for the end user's time, attention, and privacy" but now we're moving into crazy-land.

Counterpoint I work on a big boring business. I have two projects I am working on right now. One is a project that is interesting and I think will benefit the project.

The other is one that I find poorly considered and a waste of money and effort. I try to do both to the best of my ability, but for the second project it has been made clear to me that my opinion is not really appreciated and that my technical opinion is not valued this has hence killed my initiative and desire to go above and beyond or my desire to advocate for changes for the betterment of the project. Not because I am lazy or resentful I've just learned that attempting to do so on this project is a waste of time and effort and my energy would be better spent elsewhere.

I feel you there. I am also working on a project now that, I feel, is a net negative for my company. And you are right, no one is listening to me about it. And they shouldn't, as a software architect who am I to tell business owners that basing a company around SAP ERP is a good idea from the business standpoint.

However, as an internal technical team full of professionals, we are making sure that right technical decisions are taken during the implementation, and we don't allow inferior SAP tools that "work out of the box with the SAP ERP" to pollute our technical landscape, and we are not letting SAP consultants to further lock us in into their world.

That's the part where we still can be professionals and do a great implementation of a "shitty" project we don't believe in. But you are right, if we were not allowed to be professionals and if business would not respect our technical decisions, it would not be our fault to be demotivated and just do the bare minimum required not to be fired on the spot.

I think it all depends on what the goal is.

For tractable, straightforward, or routine software development, this seems very true. For middling-difficulty, this seems often true.

It's more just the edge cases - problems requiring a lot of creative thought or unique problem-solving tactics - where it seems like getting software developers to "believe" would be a huge boon.

Just as curiosity is a large multiplier to learning, genuine interest is a large multiplier on difficult mental work.

As a side note, offering "interesting" and "meaningful" work can be seen as another perk of a job listing (just like other optional benefits), especially to young or idealistic devs.

I largely agree and I have structured my career around this belief in recent years, however, I do feel the cognitive dissonance of "being a professional" despite feeling that a project is not a net benefit to society does take its toll

Nonsense. This will make your project take at least 50% more time, if not more. The dialogue that one could have with developers will bring out ideas on how to do things simpler. Also, sometimes a requirement that you have now conflicts with one that you had earlier. If you don't have a good dialogue with your developers it may be that the first requirement just gets disabled or otherwise starts to behave unexpectedly. Then the users start to complain why it no longer works and things need to be redone. Good communication with the developers can prevent such things and save rework.

Good communication has got nothing to do with whether developers believe in a project or not. The two are orthogonal.

They are not orthogonal. At all. While it is possible that a project is compelling despite terrible communication, they are highly correlated.

Orthogonal is a great word. Don't weaken it.

It's the converse that's the issue.

Projects with excellent communication that are not in the least compelling.

I tend to think that every programming project has its own charm. For some projects one has to look a bit longer to find it.

Are you finding, getting and keeping the professionals you want? In other words, do your employees seem to agree with you?

Give devs enough equity and they will question the usefulness of the project. (At least in orgs where that project is an important growth vector)

A lot of this comes down to how "do their best" is defined, as implementing things as requested would send many of the projects I have worked on careening off a cliff very quickly.

I absolutely agree.

Even worse, of course, are 'passionate' developers. They're a real nuisance.

How so? Wouldn't working with someone passionate about improving the project be useful, even if you're not equally interested?

Because it can often mean that they lack dispassionate objectivity.

How often have you seen starry-eyed people like this push their pet technology into a project just because it was their passion, but without any view as to the wider technical context or business context. They can be a real menace. Not because they aren't technically competent. But because their judgement is poor. Looked at from a distance, they aren't looking at what's best for the company or the project, but what's best for themselves.

Ah, that's fair. I definitely agree it's a problem when trying to cooperate on a program. I think it's probably more a function of inexperience or poor judgement than passion per se, but overzealousness definitely exacerbates it.