Live data from Hacker News

Why your programmers just want to code

medium.com

121–130 of 133 posts

Re: Why your programmers just want to code

#121

Earlier quoted context omitted.

Besides scandox's comment, where do you work that you can actually do that and get away with it? Where I've worked, a programmer who did that might get to decide a few things unilaterally, but not for long.

I'd say 40% of the time of my career I've been in a place where my ideas were valued and I felt like "part of the team" as a programmer, and later as a programmer/manager. Those places I stayed the longest. They make up 15% of the number of companies I've worked for (my résumé has a lot of places on it..ha!). The rest of the places I was beaten down, much like the programmer in this story. Unlike that developer, thou…

In my comment I am describing the culture at my former employer -- a culture that led to processes where you had to get your manager's permission to check out a file before you could modify it.

Re: Why your programmers just want to code

#122
post #34
post #25

Earlier quoted context omitted.

This happens if your superior doesn't critically evaluate anybody's work, and there are no code reviews. So if there's no feedback culture. At my company, my superior sometimes writes emails regarding commits, but since he doesn't write that down (waiting-for list in GTD) I figured that I can simply ignore the emails, and nothing happens. The result is cowboy coding.

My experience with code review is that code reviewer is the one holding the power and refuses to accept code until it does what customer did not wanted. If you have position without checks, including code reviewing, it will be abused.

The best reviews that I have experienced are side-by-side reviews with the author walking the reviewer through the code. The author finds most of the bugs; the role of the reviewer is to force the author to cover all the ground; asking questions where he does not understand something.

Re: Why your programmers just want to code

#123

The programmer in this story has realised this fundamental truth: The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone. What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. When it comes to what actually gets implemented — all of…

> Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to. what so you're just going to ignore everyone else and build something you think is right, because you're writing the code? I would most certainly undo your work and fire you, it would be much cheaper than selling all of your ass…

That is presuming you are able to find out what is happening -- the dysfunctional situation that I described comes about mainly because everybody is pedalling so hard they don't have time for humane man-management let alone watertight oversight and review.

In a half-way competent organisation the team is able to align to common goals and people can be trusted to work together towards a mutually agreed outcome.

It is when the organisation is run in an aggressively competitive dog-eat-dog manner -- where (for example) a five man team is responsible for its' own profit and loss; where the teams that are perceived as performing well -- that are willing to lie and deceive more aggressively -- are allowed to cannibalise budget and resources from teams that try to maintain some semblance of decency -- where your nationality and race have a bearing on whether you have credibility within the organisation -- where managers scream at each other in the corridors and conspire against each other behind their backs -- and where engineers are threatened with lawsuits should they dare to leave ...

Re: Why your programmers just want to code

#124
post #42

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you help me? I promised my friend I would meet him half an hour ago, but I don't know where I am." The man below says: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and…

If the manager / CEO / businessy business person is holistically concerned with the health of the business and the software engineer is only concerned with their domain of expertise, they are relatively childish compared to that person that is expected to know enough about everything and sincerely takes it on.

Re: Why your programmers just want to code

#125

Earlier quoted context omitted.

his “team-friendly” interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback. The easily missed point here is that Jamie, on some level, still cares. The ones this author doesn't recognize are the ones who don't give any outward sign of annoyance, because they…

> I've personally seen it exactly once. I've seen it twice. I left the first company where I saw it (I stayed for 6 years and learned more here than everywhere else else combined, despite the other problems) because despite having all of these brilliant people and alignment with front-line managers and other teams and strong process and strong product guidance the company was ruled over by a tyrant in the CEO and CFO…

[deleted]

Re: Why your programmers just want to code

#126
post #45

"He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback." I recognise myself very much in this traits. When I work on a new project, I maintain a diary with a section todo and a section technical debt. It appears, there are always many items in technical debt. The mindset of people is very infl…

I agree. I imagine the beginning of the end is, the agile standup/sprint process. Instead of addressing the code as a whole, we're reduced to picking at one piece at a time in isolation. No development without a customer issue to justify it! Especially the new guy. And to come in after a couple of years of this, and find a code base that is a pile of individual pieces in a loose spaghetti wad, is so absolutely disill…

Just realized this is now me. "A pile of individual pieces in a loose spaghetti wad" exactly describes what I've been made responsible for. Each source file shows scars of sprints where some poor fool was given a story and told "just make it work" with no concern for any big picture.

Re: Why your programmers just want to code

#127
post #119

Earlier quoted context omitted.

At the heart of it though there is a good point, the culture of a workplace can determine how developers operate. That's it but the full picture is: The culture of a workplace determines how everyone operates. Managers do not 'set' the culture and drive workers with amateur psychology, although they might like to think they do. Whenever I see the attempts to control how I operate in the workplace, I play along and go…

But how can your work be the same if attitude (ultimately) affects the work produced?

But how can your attitude be the same if the work you're tasked to produce determines your attitude?

Chicken, meet egg. People usually want agency and most would accept responsibility. When you get ordered around and your input is ignored or objectives abruptly changed, the result is loss of morale. Even techniques to deal with it can and will be perverted.

Re: Why your programmers just want to code

#128
post #112

Earlier quoted context omitted.

That sounds so...boring! Not only that, you are unlikely to advance far if you are relying on other people to tell you what to build.

I agree! You are coding ideas for people, but somebody needs to translate those ideas into code for them to work, and what might be planned might not be the best or most efficient course of action.

Sometimes it is hubris, such as where management prevents experimentation. Unlike developers who tend to be experts in the domain, managers tend to be experts at sales and management but not the domain of the product.

Yet they get to value market ideas and their impact. Moreover, they love to hide this behind anonymous "units" and "divisions" to redirect blame and responsibility.

In the past, such problems were solved by analysts and focus tests using prototypes. But when you work on the cheap, even finished applications are prototypes.

Re: Why your programmers just want to code

#129
post #42

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you help me? I promised my friend I would meet him half an hour ago, but I don't know where I am." The man below says: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and…

If the manager / CEO / businessy business person is holistically concerned with the health of the business and the software engineer is only concerned with their domain of expertise, they are relatively childish compared to that person that is expected to know enough about everything and sincerely takes it on.

And that person is either ignored or swamped in "the process". Or both.

Re: Why your programmers just want to code

#130

The programmer in this story has realised this fundamental truth: The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone. What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. When it comes to what actually gets implemented — all of…

A healthy team is a team with high social capital: a team that seeks the common good, where people clean up after themselves and volunteer to help others. Everyone wants the best idea to prevail. All this while preserving critical thinking and trusting other people with the feedback that is necessary to improve. Their most important competitor is another company. An unhealthy team is a team with low social capital: a…

To a point. When the entire team is essentially stonewalled, not given agency or overloaded it will degrade.
Post reply on HN