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

91–100 of 231 posts

Re: Things I Believe About Software Engineering

#91

Post by loxs »

> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.

For me this is not true. The type system has a bigger impact on me. If I use a language with static types + IDE, I am quite productive even while chronically not getting enough sleep (currently looking after a newborn). Probably much more productive compared to writing in a dynamic language while getting enough sleep.

And of course, that does not mean that sleep is not a huge factor. It most definitely is.

Re: Things I Believe About Software Engineering

#92

Post by Plyphon_ »

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…

The way I took it -

If your cross functional team (Product, UX/Design, Eng) are aligned, it doesn't matter if you build the wrong thing initially, because you'll follow a good agile and/or lean process to validate early and thus learn what you should be building earlier.

It's not saying 'being aligned is more important that building valuable things' - but "if you focus on building a team that functions well operationally and strategically, you'll figure out how to build the right thing quicker".

Re: Things I Believe About Software Engineering

#93

Post by prox »

jwr wrote: post #24

Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapa…

Cooper: Hey TARS, what's your honesty parameter?

TARS: 90 percent.

Cooper: 90 percent?

TARS: Absolute honesty isn't always the most diplomatic nor the safest form of communication with emotional beings.

Cooper: Okay, 90 percent it is.

Re: Things I Believe About Software Engineering

#94

Post by kubav »

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.

Re: Things I Believe About Software Engineering

#95

Post by bbatha »

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.

Re: Things I Believe About Software Engineering

#96

Post by jonathanstrange »

arexxbifs wrote: post #71
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…

I've seen the claim before that it was better in the olden days and that "no real engineer" would create software bugs, especially in connection with space flight. Meanwhile, here is a list of space flight software bugs that has cost over a billion dollars and put human lives in jeopardy: https://en.wikipedia.org/wiki/List_of_software_bugs#Space

> I've seen the claim before that it was better in the olden days and that "no real engineer" would create software bugs

But who would claim that seriously? That would be obvious hyperbole. The claim is rather that certain teams of engineers have created software/hardware combinations that, for all we know and for all practical purposes, did not have a bug and have not failed due to software error.

The development of high integrity systems is costly, though, so the discussion is a bit moot. Sure it would be possible to develop an Android app that - within the limitations of those devices and the buggy operating systems - would not fail due to a bug in its own program. It's just really expensive, particularly if the software is also formally verified. Generally speaking, it doesn't even make sense to consider "high integrity software" without the accompanying hardware. You can only satisfy real-time constraints for specific hardware anyway, and the certification and evaluation should be for software+hardware.

Re: Things I Believe About Software Engineering

#97

Post by hliyan »

By some remarkable coincidence, @JanStette's version of this (1) and mine (2) have a lot of overlap. Maybe we should all write a version of this and see if common themes emerge.

Jan and I clearly agree on coding, design and testing, for example.

1. https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1...

2. http://zen.lk/2019/08/18/Things-I-believe/

Re: Things I Believe About Software Engineering

#98

Post by _wldu »

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 agree. Group Think is bad in general. When no one is permitted to speak their mind and is encouraged to just go along with things, that's generally a bad environment.

Re: Things I Believe About Software Engineering

#100

Post by szatkus »

bilekas wrote: post #62
szatkus wrote: post #40

Earlier quoted context omitted.

Because it's much easier to change software than for example a bridge. I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well.

> 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.

Post reply on HN