Live data from Hacker News

Software development requires servant leaders

adl.io

51–60 of 209 posts

Re: Software development requires servant leaders

#51

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

Holy hell are you angry at nothing.

Big whoop you’re good at pushing hard to build software.

Wake up; it’ll be obsolete in 5 years, unlike a tunnel or bridge

You’re comparing apples and oranges and peddling some crazy emotional rhetoric

Who are you to make suggest others have to jump so high?

I’ve built homes, it was a summer job in high school 3 years in a row. Framing, plumbing, wiring.

I started writing code professionally after that last summer, in 1996. The required mindset is vastly different.

Mr chip on his shoulder is scolding someone else for not carrying a big enough chip.

Re: Software development requires servant leaders

#52

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

A key difference is that people have been sailing for thousands of years and tunneling for hundreds. We've been developing software for decades now and are learning how to do it much more quickly than we're learning new ways of sailing or tunneling. In that regard, it's a creative process and more akin to writing a book than the examples you mention. Sure, risk assessment and management are all well and good - when t…

This capture my view as well. In the past decade few of the projects I worked on were mechanical. New languages/frameworks lead to new classes of problems and much of the overtime is troubleshooting and working around those. Some time is saved by experience but not as much as I'd like.

Re: Software development requires servant leaders

#53
post #30

Earlier quoted context omitted.

While I agree with you that software projects aren't unique in having difficulty trying to estimate things, I think that emotionally it's different. If you're digging a tunnel and hit a seam of unobtanium you can go to your boss and point at the seam and say 'Look at this big rock - this big rock is very hard, we had no way of knowing it was here but now we know we have a problem". That is very different from going t…

You are referring to non-engineering managers, which will also happen in other industries, this depends more on the size of the company I'd say. Also, if you are really the only one to understand (if you are the only tech in a startup for example), then part of your job is actually to explain. Problems hit by developers are imho the same kinds that you describe with rocks: something unexpected has happened, we didn't…

Nobody will die if your webpage doesn't render but software is used in safety critical environments too.

Re: Software development requires servant leaders

#54
post #42
post #33

Earlier quoted context omitted.

Yeah I don’t think he meant “you don’t find in other industries” as “you don’t find in ANY other industries”. I mean, you’re “disgusted”? Really? Reading all this seriously makes me think you need a vacation or something.

[deleted]

Programmers ARE a spoiled and privileged class because you’re not breaking your body the same way to survive as carpenter

And that field is also pushing safety and mental health way more than it used to

To suggest there’s an equivalence to their effort and struggle as a manual laborer is self-aggrandizing nonsense itself

Re: Software development requires servant leaders

#55

Earlier quoted context omitted.

I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if i…

Of course it makes it easier to have all three roles embodied in one person, but these are very, very different skill sets. In asking for one person who's good at all of them, you're talking about a seriously exceptional human being. There just aren't enough to go around.

I'm not saying reduce the body count, I'm saying don't specialize. If you have three managers, have them do everything, don't fire two of them and give the third one the work of the other two.

If you still disagree then I think we have different intuitions about the difficulty of wearing different hats in management positions. This is somehow analogous to the split on full-stack vs. specialized development. Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.

Re: Software development requires servant leaders

#56

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines. Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet h…

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account for.

Re: Software development requires servant leaders

#57
This is the sort of article that makes me imagine a dialogue between a senior software engineer and a newb developer that goes something like this:

Newb: Hey man, I think for this project I'll write my own SQL datastore from scratch. I've looked at a bunch of them and my project, which is basically an inventory management system, is such a special snowflake that it needs its own datastore.

Senior: That would be insane. Never do that. Use what's already out there, and is tried and tested. In fact, just use postgres and make it work.

Newb: Aw, ok. I was so much more excited about writing a new SQL datastore than I was about the actual project it's for, but sure, I'll just use postgres. starts to walk away...

Senior: Hold up a sec before you go, I want to run something by you. Because our discipline, which is basically a team of people who are hired to build things on a schedule, is such a special snowflake, I've invented this totally new way of thinking about work, and of organizing a team and leading it, and there's a bunch of new terminology and I have some cool diagrams... I'm lobbying that we all switch to this at the end of the month.

Re: Software development requires servant leaders

#58

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

> Maybe try digging a tunnel through a mountain, where the kind of rocks and caveats you find on the way can make you overrun your estimates?

Usually the client doesn't call halfway through the project and tells you that the tunnel you're digging really needs to start 10 miles further up the valley...

Re: Software development requires servant leaders

#59
post #2

In my experience it is rarely enough to just "lead" more thoughtfully, which seems to be what the author here is promoting. Software development does not just require servant leaders in the helping sense, but in the working sense. The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. They have the power to move the project forward on their own,…

I disagree with this entirely, its basically the opposite of the point of the article. It sounds like the kind of leader that would have to insert their superior technical knowledge into every decision the team makes and who won't recruit the best people to take technical leadership of different aspects of the project.

Maybe we're envisaging different kinds of projects here. If it were 3-5 people building some component I'd expect there to be a technical leader in that group that can push it forward, as you say. But even they might not be the 'best' coder, whatever that means.

A 50 person project is never going to have a single person like that though.

Re: Software development requires servant leaders

#60
post #30

Earlier quoted context omitted.

While I agree with you that software projects aren't unique in having difficulty trying to estimate things, I think that emotionally it's different. If you're digging a tunnel and hit a seam of unobtanium you can go to your boss and point at the seam and say 'Look at this big rock - this big rock is very hard, we had no way of knowing it was here but now we know we have a problem". That is very different from going t…

You will never know what you don't know. That doesn't change. The question is, what do you do about it? That tunneling project probably did account encountering different materials, but maybe not for unobtainium. If the area is known for unobtainium, that's obviously a research miss. If this is the first seam ever encountered within 500 miles, that's straight up unexpected findings. Most situations usually lie somewh…

I wholeheartedly agree. I think it’s however more of an unacceptable problem in non technical industries who hire technical workers.

For instance, risk assessment isn’t all that helpful if your deadlines are bumped up by weeks or months and the client or your coworkers or bosses have no concept of why the project “can’t just be done immediately” when you’ve planned for added weeks. Even worse when they don’t understand why they can’t suddemly throw new variables at you after all estimates have been completed like new, potentially breaking features. Last minute scope creep is a real problem in some non-technical fields because the whole software solution is often some “nerd magic” and there’s no desire to understand the problem or solution except where to click and can they have it all by the end of the week. Theoretically maybe it could be done, but there goes all window provided for unexpecteds.

Admittedly, this is probably more of an organizational flaw than directly associated with the subject at hand, but a very real tangent.

Post reply on HN