Heisenberg Developers (2014) • Hacker News Board

Re: Heisenberg Developers (2014)

#111

Post by taylodl » Wed, Feb 03, 2016, 1:26 PM UTC

seivan wrote: post #102

taylodl wrote: post #92

Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.

I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default. F-35?

Not all engineering projects are successful either. What I'm saying is there's a lot of similarities between these disciplines and so there exists a large body of knowledge and experience from which we can cull and learn.

Re: Heisenberg Developers (2014)

#112

Post by vinceguidry » Wed, Feb 03, 2016, 1:32 PM UTC

johnsonjo wrote: post #64

vinceguidry wrote: post #30

Earlier quoted context omitted.

I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.

> I found it easy enough. I learn new things for fun. I don't consider it taxing at all I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the a…

There's an art to learning. I work on that too. The better I get, the quicker it takes me to integrate new ideas.

> Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.

If you look at all the other skilled professions you'd find similar dynamics. You spend a lot of time paying your dues. Once you've paid them, then you have to learn how to turn them into a career. What's unfortunate about development is that there's never that moment where you call yourself done with the skill-building part and start on the career-building part. Other professions have that, but development does not and probably never will. It's too big, and changes too much for an examination to be worthwhile.

> If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem.

That sense of magic is what keeps salaries relatively high compared to other individual contributors. It also means that we can cloister ourselves into priesthoods where those with the arcane knowledge can band together against the uneducated masses. I used to think coders needed a union, until I realized we've already pretty-well self-organized into one.

Re: Heisenberg Developers (2014)

#113

Post by vinceguidry » Wed, Feb 03, 2016, 1:46 PM UTC

badminton1 wrote: post #44

vinceguidry wrote: post #11

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable. The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people wi…

What the author describes is that the manager manipulated the consensus building in the team, by adding friends to the team so he can start ignoring them. Consensus building is a key part of any organization and doing this is not ethical. Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out me…

This is almost completely wrong.

Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job.

Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?

Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve.

Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.

Re: Heisenberg Developers (2014)

#114

Post by allengeorge » Wed, Feb 03, 2016, 1:48 PM UTC

seivan wrote: post #103

donatj wrote: post #2

This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I'…

Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html One day I hope to find some place small that applies that by the 'book'. My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant…

Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.

Re: Heisenberg Developers (2014)

#115

Post by FLUX-YOU » Wed, Feb 03, 2016, 1:51 PM UTC

taylodl wrote: post #92

Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.

Software dev isn't driving this, business is. NASA coding practices prove we can do exactly what you're saying, but businesses don't care for (or don't often need) the rigor that NASA requires. I'd bet a lot of people would enjoy participating in NASA-quality projects if only to experience it and feel good about producing rock-solid code even if they only commit 50 lines total, but they are very rare.

Re: Heisenberg Developers (2014)

#116

Post by vinceguidry » Wed, Feb 03, 2016, 1:56 PM UTC

bb88 wrote: post #74

Ace17 wrote: post #54

Earlier quoted context omitted.

The success/failure of a project hinges on lots of things. Amongst them, code quality, which heavily dictates your reactivity. Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killin…

> Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.

It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology.

Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.

Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.

If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.

Re: Heisenberg Developers (2014)

#117

Post by vinceguidry » Wed, Feb 03, 2016, 2:02 PM UTC

pile_it_high wrote: post #81

vinceguidry wrote: post #30

Earlier quoted context omitted.

I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.

I envy you. Mostly being a programmer learning "new" things is the same as a taxi driver moving to a different city every half year and learn the new topology. In both cases, you're not learning anything that is fundamental to human knowledge.

You can work backwards towards first principles. In my case, whenever I learn something new, I always stop to boil things down to the essentials. What does this new tool / framework actually do, what am I hoping to accomplish.

Then I try to work it as best I can into my current toolset. For me, all projects get a repo on Github, and I get the nasty infrastructure bits implemented first, like deployment workflow, before actually working on the problem.

There's an art and craft to learning new things that I find fulfilling all on its own without having to turn it into something lofty.

Re: Heisenberg Developers (2014)

#118

Post by seivan » Wed, Feb 03, 2016, 2:04 PM UTC

allengeorge wrote: post #114

seivan wrote: post #103

Earlier quoted context omitted.

Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html One day I hope to find some place small that applies that by the 'book'. My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant…

Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.

You could get overall progress even with separated boards.

Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different?

Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.

Re: Heisenberg Developers (2014)

#119

Post by iamthepieman » Wed, Feb 03, 2016, 2:24 PM UTC

This is similar to an experience I had. Me and the small dev team were being micromanaged. But we were getting lots of new customers for version 2.0 of our main software product and specifically targetting feature relases to snag certain customers, I feel like it worked from a business perspective.

We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily.

most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior.

But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job.

I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.

Re: Heisenberg Developers (2014)

#120

Post by simula67 » Wed, Feb 03, 2016, 2:32 PM UTC

gyardley wrote: post #42

Oh, the joy of being a product manager for the particular type of programmer who, by virtue of being a programmer, also knows absolutely everything about absolutely everything. This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you wer…

> This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month

Software development is about figuring out how to do something. Sometimes you can still kind of estimate how much time something will take, especially if it is some grunt work. But truly meaningful changes are unestimatable. If I told you 'I want you to make me some Japanese kuhoo kuhoo. I wont tell you what it is, what goes into making it and if it is even a real thing that can be made. Now tell me how much time it will take', how can you react to that ? I am not saying you acted this way, but I have seen managers act this way.

> but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree

Why not just let the developers do all these things ? We have been asking our product managers for customer visits for years. Would that be the end of the world ?