Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development requires servant leaders

adl.io

Post reply on HN
Print view View original

81–90 of 209 posts

Re: Software development requires servant leaders

#81

Post by groby_b »

jonstokes wrote: post #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 insan…

You just might not have experienced decent leadership.

Servant leadership doesn't mean you do what your reports want. It means you enable your reports to make good decisions, instead of deciding for them. It doesn't mean you don't teach, or you don't share experiences.

Let me quote from the original: "The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?“

Do you think the senior can answer "yes" to this if they just acquiesce to everything?

Re: Software development requires servant leaders

#82

Post by ppflwn »

jonstokes wrote: post #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 insan…

I'm not sure the applying the ideas in the article requires Servant Leaders™ to explain to the people they're leading what Servant Leading™ is. I read it more as, if you're in a leadership position, here are some ideas which might make you more effective.

Re: Software development requires servant leaders

#83

Post by ianwalter »

gregoriol wrote: post #38
shriver wrote: 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…

They're not even necessarily referring to non-engineering managers. It's often difficult to explain to engineering managers or other engineers why something won't work or requires more work/research if they themselves have not done the work. The engineering manager isn't even necessarily that familiar with the technologies being used or experienced in the specific problem being solved.

When digging a tunnel, there is a finite number of kinds of rock that you can hit. It's well within the realm of possibility that an experienced engineer is familiar with any of the rock they will encounter, even if they didn't expect to hit them when digging. This is generally not the case with software. Even as an experienced engineer you continually hit issues that you've never encountered before and don't know how to solve without spending a significant amount of time doing research or trying out different solutions.

The upper bounds of complexity are higher in software than construction. It's not narcissism, it's just the nature of that kind of work.

Re: Software development requires servant leaders

#84

Post by repolfx »

jdmichal wrote: post #37
shriver wrote: 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'm not sure argument by reality TV is very effective. Obviously everyone tries to budget time for the unexpected. That doesn't mean it's equally difficult in all professions.

Re: Software development requires servant leaders

#85

Post by phakding »

humanrebar wrote: post #64
phakding wrote: post #32

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never had to invent different kind of leadership and procedures or change office floor plans or hire outsider non-engineers as our (scrum) masters, or talk about the client as stake holders etc. Sorry about hurting your agile feelings!

Software is incredibly open ended. Maybe even more open ended than writing in English because software can be written in several languages or even in brand new ones. The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.

If you are choosing multiple languages for a single project or Keeping your project "incredibly open-ended" no amount of methodologies is going to stop you from going over the cliff.

Re: Software development requires servant leaders

#86

Post by jdmichal »

Cederfjard wrote: post #78
jdmichal wrote: post #29

Earlier quoted context omitted.

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're u…

Is this how you/your team/your company work? Do you know of any resources you would recommend for those of us who are interested in learning more?

This is generally part of the "No Estimates" movement. I learned about it from an internal talk, but I will ask the speaker if he has any resources I can point you to.

We are not there yet, but are moving in that direction. We weren't previously even collecting the metrics required to create models in the first place, so we didn't have any data.

Re: Software development requires servant leaders

#87

Post by Tyrek »

CamTin wrote: post #50
CamTin wrote: post #18

Earlier quoted context omitted.

This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they h…

I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a di…

In most law firms, there are two classes of lawyers - employees (salaried, with bonuses) and partners (equity profit share). Generally, partnership takes close to a decade to obtain, and generally requires a buy-in into the partnership. The 'fiction', as you refer to it, is real - they are co-owners in the business, and should be treated with some level of respect. Generally, partnership structures are closely associated with the professional services industry as it more closely aligns with the industry structure and how work is delivered - teams are often cobbled together out of the firm's employee resources, and work is overseen by one or more of the partners. As teams may be of varying sizes, it does not make sense to chain individuals to a specific 'boss' that they may or may not be working with.

Re: Software development requires servant leaders

#88

Post by mooreds »

groby_b wrote: post #81
jonstokes wrote: post #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 insan…

You just might not have experienced decent leadership. Servant leadership doesn't mean you do what your reports want. It means you enable your reports to make good decisions, instead of deciding for them. It doesn't mean you don't teach, or you don't share experiences. Let me quote from the original: "The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become…

I think GPs point was that building cohesive teams is a known art and yet software folks keep trying to reinvent the wheel.

Re: Software development requires servant leaders

#89

Post by bluGill »

DougWebb wrote: post #71
bluGill wrote: post #56

Earlier quoted context omitted.

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 f…

I've been developing CRUD apps for my company's clients for eight years. They're all superficially the same, but every single one of them has had something unique about their schema design, and they all have different business rules (in a general sense and in specific details) that make every project unique. We have a model that gives us ballpark estimates before we get into detailed analysis, but every time a custom…

I was just talking to a dirt moving contractor, he would say essentially the same thing as you.

Re: Software development requires servant leaders

#90

Post by jdmichal »

humanrebar wrote: post #72
jdmichal wrote: post #29

Earlier quoted context omitted.

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're u…

> Previous work shows we can handle a project of this size in 6 months 85% of the time More like: Previous work shoes that this project should take between one week and eighteen months at a 95% confidence interval. ...there aren't many projects one can do 300 times to narrow that window. And asking for a date instead of a confidence interval is asking for an ambiguous estimate in the first place.

Another tenet is that work is work. You attempt to break the work into chunks that are close enough to previous work efforts to use your model. If you can't do that, then you don't actually have any idea of what you're doing yet. Which is fine, but you certainly can't estimate in that state.
Post reply on HN