Things I Believe About Software Engineering
blog.wesleyac.com
Things I Believe About Software Engineering
1–10 of 231 posts
Re: Things I Believe About Software Engineering
#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 these hours are going to happen. Also, sometimes it's 2, sometimes 0 and sometimes 8.
> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.
(Yawn) Indeed...
Re: Things I Believe About Software Engineering
#3> 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 of the product isn't clear across the whole team, it doesn't matter if any one individual has a bunch of brilliant ideas for/about the product, because you aren't all working towards the same goal.
Re: Things I Believe About Software Engineering
#4> 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 misalignment :)
Re: Things I Believe About Software Engineering
#5> 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…
I'd offer that the "alignment" is substantially a function of the management/leadership on display.
Re: Things I Believe About Software Engineering
#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 hours? Or is burnout (or another complication) a more likely outcome? Has anyone tried this?
Re: Things I Believe About Software Engineering
#7> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.
I think it's worse than this: Defining correctness for any nontrivial system to the level of detail required by software is beyond the capabilities of any human or group of humans operating to a deadline. The only way to get there is to pare down the scope such that physically possible things are defined to be out of said scope, such that the system punts and relies on humans to figure it out.
This has implications for job automation.
> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.
Attempting to prove yourself wrong is a massively valuable and underutilized skill. If you get a theory, develop a test which the theory is vulnerable to, such that if the test comes out a certain way the theory is disproven, and then run that test. Some people seem unable, or unwilling, to think like that.
This has implications for software testing. It has implications for all kinds of testing.
Re: Things I Believe About Software Engineering
#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 approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.
Re: Things I Believe About Software Engineering
#9Earlier quoted context omitted.
> 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…
I'd offer that the "alignment" is substantially a function of the management/leadership on display.
Sure, but hopefully the choice isn't a binary one between "lack of alignment" versus "management/leadership dictates", since that would be evidence of a rather toxic team culture.
Re: Things I Believe About Software Engineering
#10> 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…
How do you define productive so that you could add a time goal to it?
Because I read it as "There are on average about two hours of productive in-context work to be done and the other hours are about building that context for those two hours that not often transfer between days." You can't add 10 minutes to that.