Uncomfortable Truths in Software Engineering • Hacker News Board

Re: Uncomfortable Truths in Software Engineering

#201

Post by ReleaseCandidat » Wed, Dec 15, 2021, 3:30 PM UTC

roenxi wrote: post #73

varjag wrote: 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…

Typing is almost a no-loss addition though. If your function takes an integer argument and someone might pass it a string, that is a bug. It is quite hard to argue that a typing mechanism won't improve code quality, and it is very lopsided in the amount of time it takes to type a function vs. debug something that would have been caught by a type system. There are edge cases that can be argued all day, but if some lar…

> If your function takes an integer argument and someone might pass it a string, that is a bug.

What if you pass it a float and that's converted to an integer?

Re: Uncomfortable Truths in Software Engineering

#202

Post by mamcx » Wed, Dec 15, 2021, 3:32 PM UTC

StevePerkins wrote: post #16

varjag wrote: 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…

Number one, static type checking is hardly a "new tech" for which the industry is in a "newlywed period". If anything, it is the middle-aged wife that the industry's crawling back to, as the passion fades from its dynamic mistress dalliance. Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we'…

Also, TODAY type checking (and more important, how Types are used) is not the same than YESTERDAY types usage.

Java, C++ and similar are terrible benchmark for it. Before, types were almost for do taxonomy, with limited help to actually write CORRECT code, and more important, MODELING the domain was very verbose and with limited advantages!.

Against that, no static types makes more sense. With o without the end result, result-wise was kinda the same, only that without you remove a lot of noise on the codebase.

Only after a bit of the ML/oCalm/Haskell/etc type-system get in, and NULL removal becomes truly feasible, and some of the failures of error-prone software and how WRONG JS,C++ and for some extend, Java become more and more evident, then modern static types start to leverage a greater return of investment.

It also come together with other improvements in tooling (that make more enjoyable type inference on IDEs, for example), composability, iterators/generators, etc and you get a very nice toolset.

This is where everyone is converging, in some way or another.

Re: Uncomfortable Truths in Software Engineering

#203

Post by namdnay » Wed, Dec 15, 2021, 3:33 PM UTC

bumby wrote: post #168

WhompingWindows wrote: post #74

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…

> And yet, their jobs are ESSENTIAL and we need people to do them even though they're grueling and underpaid. I think this touches on an uncomfortable point that many people don’t acknowledge: our current system generally* pays people according to how much they contribute to the economy and not by how much they contribute to society . The scalable nature of software means developers can disproportionately add value t…

To be more precise, it pays people for their differentiated contribution to the economy. If there’s no one to open the office doors in the morning, productivity is 0. Does that make the security guard the highest paid staff? Of course not, because he’s easily replaceable. A developer whose absence will only lose the company 1k a day may be paid 500 a day, because the few people who can bring in those 1k all want more

Re: Uncomfortable Truths in Software Engineering

#204

Post by fatbird » Wed, Dec 15, 2021, 3:33 PM UTC

musingsole wrote: post #147

akavel wrote: post #10

Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort,…

> Question is, can anyone design & implement a language that would have all of that, and still be readable and understandable to a common programmer No, because exception handling and the answer to "what type are these data?" are product questions. Hard questions that no one really wants to work out because what if our customer base wants something completely different in 6 months? This is largely reflected in cloud…

But don't argue "strictness" is "correctness"

I feel my mind expanding right now the same way I did when I first heard "concurrency and parallelism aren't the same thing".

Re: Uncomfortable Truths in Software Engineering

#205

Post by mgaunard » Wed, Dec 15, 2021, 3:34 PM UTC

Pair programming or mobbing are a huge waste of resources.

I know that myself I can't actually get anything done unless I'm in control.

The only use this sort of this could have is to train juniors or hand over projects.

Re: Uncomfortable Truths in Software Engineering

#206

Post by MathCodeLove » Wed, Dec 15, 2021, 3:34 PM UTC

vlovich123 wrote: post #189

MathCodeLove wrote: post #161

Earlier quoted context omitted.

I don't understand this weird fetishism with getting X demographic into software/tech. Naturally I don't think that any demographic should be restricted from entering the field, and everyone should be equally encouraged and provided the same opportunities, but more and more I see these pushes for trying to pump the numbers of specific demographics. If someone wants to join the industry, great. If not, also great. I t…

I think the general perception is that women often get turned off not by the work, but by the male-dominated environments. This can be due to subtle issues and sometimes due to non-subtle issues. You want to go out of your way to make it a friendly environment in those cases. Basically, do you want women to have the same shitty experience when they were breaking through various male-dominated fields in the past (e.g.…

The issue is the same in reverse. I've heard horrible anecdotes by male friends in female dominated industries such as teaching, nursing, etc. Why is the same societal push not happening in those industries? I never said we shouldn't strive to be welcoming and to cultivate a friendly environment for all, just that the intentional push for more of any specific demographic seems strange to me. Shitty people are going to exist everywhere regardless. A twitter campaign shouting about the injustices of the industry and pushing for more women in technology isn't going to change that. The people that need to hear the message being conveyed there aren't going to listen, and the people who are listening don't need to hear the message because they likely aren't already shitty people.

Re: Uncomfortable Truths in Software Engineering

#207

Post by selestify » Wed, Dec 15, 2021, 3:34 PM UTC

SamoyedFurFluff wrote: post #188

MathCodeLove wrote: post #161

Earlier quoted context omitted.

I don't understand this weird fetishism with getting X demographic into software/tech. Naturally I don't think that any demographic should be restricted from entering the field, and everyone should be equally encouraged and provided the same opportunities, but more and more I see these pushes for trying to pump the numbers of specific demographics. If someone wants to join the industry, great. If not, also great. I t…

It’s hard to know if an environment is hostile to you or not if there are no examples of safety. For example I would hesitate to join a magic the gathering group if I didn’t first check that they’re friendly to newbies. Especially because I know magic the gathering can vary in experience and that a group that isn’t friendly is not an outlier. If I think about it this way I can understand why a woman might not want to…

I don't disagree at all with making programming welcoming to newbies, but if Magic the Gathering were something you were really interested in picking up, wouldn't you look around for a newbie-friendly group to join instead of just giving up on the game altogether?

How many of us started tinkering with programming at a young age out of pure curiosity or interest in how cool it is, without any regards for how viable of a career path it is later in life? It seems most of us who did just that were boys. At some point you have to consider that there's perhaps an innate aggregate imbalance in how interested each gender is in programming, or in how much each gender responds to financial incentives -- which would explaian both why countries that are more gender equal and more prosperous tend to have a greater degree of gender imbalance in STEM.

Re: Uncomfortable Truths in Software Engineering

#208

Post by gonehome » Wed, Dec 15, 2021, 3:35 PM UTC

pc86 wrote: post #191

gonehome wrote: post #142

Earlier quoted context omitted.

Imo this is related to value provided. It’s why an excellent tutor can make serious money and be hired by wealthy families to teach kids. Good teaching is a scarce resource. Many (most?) teachers are bad and the existing incentives don’t require them to be good. It’s hard to fire them and public schools have issues which limit selection and competition. Perhaps harsh, but some of the dimmest people I knew in highscho…

I don't think that's an exception, as government funding and capitalist market are more-or-less mutually exclusive, even in capitalist countries. Nobody in a state government makes more than the governor, nobody in the federal government makes more than the President, etc. And for social work specifically, "real evaluation of skill" is going to raise more than a few eyebrows.

Yeah, I think these are all fair points.

Re: Uncomfortable Truths in Software Engineering

#209

Post by simion314 » Wed, Dec 15, 2021, 3:37 PM UTC

merpnderp wrote: post #82

simion314 wrote: post #62

Earlier quoted context omitted.

>Well, good thing then that the "means of production" for software development consist of a 500€ laptop, which is well within reach of just about every programmer in the Western world. Sure, now tell me your opinion on this idea I have Today for music there are many parasites that suck the profits and creators barely get something. So my idea is to make a cooperatives (or non-parasitic company) to help the creators o…

When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care.

>When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care.

My issue is with "free markets" solve everything when most of the time you don't have free markets(like when you have too few competitors or when you have collusion not to compete ) , or when you forget to specify that free market would solve the problem but only after you make illegal all the bad or evil practices companies will abuse. If someone is an economist is there a theorem /law that proves that imperfect free market will covere to an evil state so you always need supervision to intervene when you notice the effects and apply a correction/bug fix ?

In my example with mobile applications we don't have free markets , where free market would mean you have many agents competing to offer you something, we have basically 2 competitors and this 2 are happy to be in a balance and share this big pie then aggressively competing to make happy the custoemrs but reduce their profits.

Re: Uncomfortable Truths in Software Engineering

#210

Post by agumonkey » Wed, Dec 15, 2021, 3:39 PM UTC

Workaccount2 wrote: post #150

Well if we're just gonna bash software guys here.... The arrogance stands out for me. I have worked in many different fields and with a range of engineers (EE,ME,CE), none come close to the general aura of big ego and arrogance around software guys. It's similar to the levels seen in finance guys. Its like there has to be some relationship between compensation and true value, where ego makes up the difference. Of cou…

I wonder if it was the case in the previous decades.

I assume that a lot of this comes from the fact that computing is now more than trendy, and being knowledgeable on it makes you feel like king of the hill.

Also lots of people going into computing, knowing the recent history. Strong opinions about things based on the last 10-20 years, choosing their little church. While having next to zero knowledge about previous history (tech or even business in general), nor fundamentals about computing, but they have enough data to flood you with their certainty :)