Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

361–370 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#361
post #355
post #354

Earlier quoted context omitted.

> > but I'm uncomfortable referring to non-techs as "muggles." Some of the least-computer-tech-savvy people I know, are doctors, lawyers, and scientists (and I actually know quite a few). > That's fine, but it doesn't make you INHERENTLY BETTER than people who are color theory nerds or whatever. Consider that this meaning of the word is only used by the antagonists in Harry Potter . Everyone else uses it in a neutral…

Oh man, a pedantic HP correction. That takes me back! Unfortunately, that it isn't the term's colloquial usage, and as a descriptivist, I fall on the side of how language is used by its native speakers. Rather like (staying in the realm of YA fiction) the Hunger Games as an actual big screen spectacle was rather...uncomfortable from an actually thematic standpoint.

I'm not so sure it is. I generally don't see it used like that, and apparently neither does the author:

> This used to say “muggles” but several people pointed out that this has negative connotations. One of these days I should actually read Harry Potter

Re: Uncomfortable Truths in Software Engineering

#362

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

> I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money.

I don't know about that. Software scales almost infinitely. Impossible to double the number of billable hours or patient load of a cardiologist outside of an herculean effort, but software folks can easily 10x the number of people they bring value to in a short amount of time.

> We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are making great money by utilizing the greatest tool of all time: the computer.

Honestly, medical school isn't really the correct example to use because it's not efficient at all.

The big reason medical schooling is so hard is because they have to get a completely unrelated undergrad before even thinking about applying to med school. That means racking up serious debts before even knowing if you are going to get admitted. You can imagine how that fosters a culture of diversity and inclusion and help poor, often non-white, applicants reach medicine when the first step is to get into 6 figures debts with absolutely no guaranteed income.

Other countries with similar health outcomes for their population simply admit freshmen into med school right away.

Residency is something else. It's overworked since the total number of residents is capped by the AMA (also you have to fly-in to your residency interviews on your dime, so much for underrepresented applicants!) and honestly there's a lot of cargo culting. 48 hours shifts with no sleep because it's believed that it's impossible to correctly handover patients from one medical professional to the other (hint, this is a solved problem in a lot of high stress cognitive disciplines outside of healthcare). It's a culture of always working harder instead of working smarter, and the people take pride in that strangely enough.

All it really does is create a moat and allow AMA members to charge more because they made themselves scarce.

> Meanwhile, our friends who are teachers, firefighters, child-care workers, etc. are doing tough work daily for less pay, perhaps simply because they didn't use computers much or didn't like them. And yet, their jobs are ESSENTIAL and we need people to do them even though they're grueling and underpaid.

Firefighters tend to have nice pension funds in a lot of cities.

Teacher's pay is incredibly interesting. Engineers are paid on results (this is even more true at serious tech companies where a significant portion of ones earning will be stock comp) while teachers are paid a government approved rate no matter the results.

I know a lot of parents that would pay serious money to teachers based on results (if their kid can get into Stanford/MIT for instance) if said teachers could show a track record of having previously mentored alumni for instance. Instead, the premium is now captured by real-estate since parents that care will pay extra to get into a good school district.

Re: Uncomfortable Truths in Software Engineering

#364

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

15. Some of the highest paying software jobs are at companies that profit from attention/marketing and might not have a net positive contribution to society.

Re: Uncomfortable Truths in Software Engineering

#365

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

[deleted]

Re: Uncomfortable Truths in Software Engineering

#366
post #351

Earlier quoted context omitted.

Static typing is net 0 cost. We don't need to be "honest" static typing is obviously not free you need to think of types. The real revelation was that the cost of dynamic languages far exceeds the cost of a statically typed language.

You're not wrong, but yet you are. There were failures with Ada as well as I recall. Statically typed. Ahead of it's time. But in some critical use cases, it failed. It also cost a lot to maintain. Compilers/IDE's were super expensive. Yet there were cases of undefined behavior that you still had to (hopefully) catch in a peer review. This was the case of the Arianne 5 rocket explosion caused by software written in s…

>Java and the log4j mess are similar. It's a statically typed language, but a poorly reviewed code base. The static typing didn't catch the security hole. And it's cost the US millions of dollars so far to fix it.

This is a ridiculous statement and just really devalues everything you are saying. How is a vulnerability in a library that is completely orthogonal to typing relevant in this discussion. Static typing never claimed to cure programmer stupidity.

Also when I say static typing I mean languages with good type systems, as much as people like to say typescript is bad because it's based on javascript, at least null errors are impossible if you are using strict mode unlike Java and Go where any variable could potentially be null and the compiler wont tell you if you have unhandled null cases.

Re: Uncomfortable Truths in Software Engineering

#367

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

No. Lots of programmers hate it. Very common reason for new hires quitting at an XP shop I worked at. I expect that's why the author qualified the statement with "if both pairers can handle it".

Note that your comment also identifies a key value of pairing (if you can stomach it). When the model your are building is undocumented/implicit and can only be constructed in your mind by careful solitary thought, then you have a weak system design. But a pairing session can only succeed if you make the model explicit. So pairing has to start with constructing a shared model of the work (hard). It turns out, once you can share a model between two people verbally, turning that knowledge into documentation and/or refactoring is relatively easy.

To the the individual programmer, this can seem like extra (wasteful!) effort. Unfortunately, it also means they are likely to make another inscrutable addition to the pile of Jenga that is clear them in the moment, but will be opaque to all next Monday. Mind you, if your management is running a ticket mill and doesn't value design or documentation, that is the right thing to do.

Re: Uncomfortable Truths in Software Engineering

#368
post #177

Earlier quoted context omitted.

> Working as a software developer without a passion for coding is kind of like doing math homework every day for the rest of your life. I disagree. I coded for fun once, as a kid, and have never felt the need to do it again. If I never coded again, I wouldn't even notice because I my passions lie elsewhere. But working as a software developer is still tolerable because I'm just sitting at a desk, typing on a computer…

Are you above 35?

I'm curious to learn how that is relevant to my post and what assumptions you make about people around this topic based on age

Re: Uncomfortable Truths in Software Engineering

#369

Is mobbing really better than pairing? I've never done it. Sounds awful. I got into this game to have long stretches of solitary work, that's when I'm at my best. Not entirely obviously, I still work on a team. Anyway, pairing can work well under the right circumstances, curious to hear anyone's take on whether mobbing works or not.

On the teams I've been on that mobbed extensively there were still people who preferred to work alone. Fortunately the other team members respected that everyone has a different preference and work style. Sometimes it's good to stretch one's comfort zone to try new things, and I'd encourage those who haven't tried mobbing to try it occasionally, but I wouldn't recommend it as something to do all the time. If it's a forced thing or something you do without question or exception, it'll easily become one or two people doing all the work with another just watching or joking around, and sometimes it's not easy to recognize who should be splitting off and who should be staying on, so often everyone stays on with different people alternately drifting in and out of an engaged, participatory state.

Re: Uncomfortable Truths in Software Engineering

#370
post #6

There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive. Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will…

Agreed, just because more companies are adopting something and saying it helps doesn't mean it actually helps. There's too much incentive for spin and arguable claims of success.

Additionally for things like static typing, the larger the company the more risk-averse people tend to be within the company so things that give a feeling of safety like type-safety are going to be a much easier sell.

Post reply on HN