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

Things I Believe About Software Engineering

blog.wesleyac.com

Post reply on HN
Print view View original

141–150 of 231 posts

Re: Things I Believe About Software Engineering

#141

Post by TheOtherHobbes »

szatkus wrote: post #100
bilekas wrote: post #62

Earlier quoted context omitted.

> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as wel It's extremely dangerous, and software is quite comparable to a bridge. Imagine starting at both sides of the river and the bridge not meeting in the middle. Changin requirements / features is very simular. And while on paper it sound like no problem, thats when you need to push back against your PO/W…

Yes, there are some analogs to bridges, but software is much more flexible than concrete. We can pretend we're building a bridge, but there could be another company, that is more comfortable with changing requirements and may deliver their product later, but more suited to a market.

Software isn't more flexible than concrete.

Software looks as if it should be more flexible than concrete.

But it really isn't.

Re: Things I Believe About Software Engineering

#142

Post by ProZsolt »

marcosdumay wrote: post #111
veeralpatel979 wrote: post #19

Earlier quoted context omitted.

For me, I think I can achieve 8 hours if: - I'm working on something I'm interested in - I feel like there's upside for me if the project succeeds - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office - It's a quiet area where I won't have people interrupting my flow state - I'm not blocked on things I need to know - I'm working on something…

> - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office > - It's a quiet area where I won't have people interrupting my flow state It's amazing how much an office fights against productivity.

That's why I stay home when I need a long stretch of productive time on one or two things.

But the office has upside when the task is not well defined or I work on a lot of small stuff. At home, my brain will wander around more easily between context switches.

Re: Things I Believe About Software Engineering

#143

Post by tr1coder »

watwut wrote: post #22
tr1coder wrote: post #6

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive h…

I tried something like that multiple times - removing all distractions and non work or replacing them by educational activities. Each time it lead to overall slowing down. Peek ceased to be as good. Once it lead to depression, when I replaced all entertainment and chill in my life by "productive activities". You can do that in short term, the real problem is usually when I tried that for weeks. Some amount of downtim…

Do you think that those outcomes would not be so detrimental if you did those tweaks more gradually, say over a year period you would get from 2 hours of focused productivity per day to, for example, 5 without those side-effects?

Re: Things I Believe About Software Engineering

#144

Post by ProZsolt »

dsego wrote: post #65
veeralpatel979 wrote: post #19

Earlier quoted context omitted.

For me, I think I can achieve 8 hours if: - I'm working on something I'm interested in - I feel like there's upside for me if the project succeeds - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office - It's a quiet area where I won't have people interrupting my flow state - I'm not blocked on things I need to know - I'm working on something…

> I'm working on something that's been de-risked. I know what I need to do and I know how to do it Thanks for including this one. I think the biggest stresses in my dev career have come from times where I didn't really know what needs to be done or when I was way out of my depth. I believe this reason alone was a huge driver of my procrastination in the past, especially when I was the lone programmer on the project.

That's why I hate doing interviews and always procrastinating when I need to find a new job. Once I talk to an engineer I know if the job is a good fit for me or not, till then I fell HR/recruiters just wasting my time.

Re: Things I Believe About Software Engineering

#145

Post by LandR »

veeralpatel979 wrote: post #11
mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Writing "correct" software is possible IMO, but is it worth it? For most applications, is it worth spending several times more time and resources in order to make it "correct"? I don't think so.

Everyone seems to think that, but I feel this ends up being death by a thousand cuts.

I don't know a single piece of software on my computer right now that doesn't crash, act weird, hang or do something else to annoy me on a daily basis.

Now yes, each infraction might be just a minor niggle, but god it adds up!

By the end of the day, all the bugs that on their own shouldn't be too bad, leave me frustrated as hell and wanting to say fuck everyone and just go live in the woods.

It's especially worse when I know this shit doesn't need to happen.

Re: Things I Believe About Software Engineering

#146

Post by dadarepublic »

_petronius wrote: post #3
einpoklum wrote: post #2

> Being aligned with teammates on what you're building is more important than building the right thing. So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Strongly disagree with that. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Here I mostly agree. The thing is, that you don't know in advance when…

> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Seems like a very unfair restatement of what the author said. I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." Or to phrase it another way: if the understanding…

This is pretty much how I grokked the point.

Having a common vision is critical in team building and in actually building the right/correct/good thing.

Re: Things I Believe About Software Engineering

#147

Post by pfarrell »

einpoklum wrote: post #2

> Being aligned with teammates on what you're building is more important than building the right thing. So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Strongly disagree with that. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Here I mostly agree. The thing is, that you don't know in advance when…

> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)?

That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate.

I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and effort to make happen.

I've ruminated on Jeff Bezos/Amazon's "Disagree and commit" leadership philosophy a bit and think it pertains here.

  Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is 
  uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the 
  sake of social cohesion. 
  Once a decision is determined, they commit wholly. [0]
Where I think "leaders" is a quality of a person's actions, not a job title.

[0]: https://www.amazon.jobs/en/principles

Re: Things I Believe About Software Engineering

#148

Post by ProZsolt »

kubav wrote: post #94
tr1coder wrote: post #6

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive h…

I found that best way to improve productivity is automating development work as much as possible. 2-4 productive hours a day are enough if you spent it on solving important problems. I have always worked less hours than my colleges with roughly the same amount of work done and the same error rate because they are refusing to change their workflow.

100% this.

Write test for everything, don't do manual testing. If the test is green my code is good. Don't spend time manually testing your code.

Touch typing was a huge improvement. I'm not a fast touch typer so it wasn't really improved my typing speed. It's more of that I outsourced my typing from my brain to my hand, so while I type I can stay focused on the problem.

Re: Things I Believe About Software Engineering

#149

Post by Agathos »

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Many successful interplanetary probes have launched with significant faults that had to be patched or worked around to complete the mission. Luckily the teams are usually able to do that.

Re: Things I Believe About Software Engineering

#150

Post by username90 »

bbatha wrote: post #95
bartread wrote: post #70

> Being aligned with teammates on what you're building is more important than building the right thing. I don't buy this. I'm not sure these two things should be placed in opposition (or at least tension) in this way. It makes for a nice soundbite but I don't think it withstands scrutiny. I've seen and worked in teams where alignment was great and we all worked really well together but, at the end of it all, nobody b…

I read that as building “the right thing” there are certain architectures that are pretty well known to be best practices at scale, or at least are fad enough that that’s what the consultants can push. On the other hand a well aligned team that meets business objectives while using out of date language, framework, unscalable architecture, etc delivers a lot more value and is generally easier to be a team member of.

Then he should have said "building the thing right" rather than "building the right thing".
Post reply on HN