4 ms·

> And, I would say that the number of jobs that require the mastery of the craft is not large. This mindset is how we end up with layers upon layers of badly d

> And, I would say that the number of jobs that require the mastery of the craft is not large. This mindset is how we end up with layers upon layers of badly designed and buggy software that underpins almost every aspect of modern life. Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by an architect who knows just enough to complete the job and does not care a bit for more? It does not take mastery to write one-off scripts that "get the job done". However, they will probably not be a general purpose solution of the problem at hand, ignore corner cases, contain bugs… and the real test comes when requirements inevitably change. If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum.

Yiin 5y ago
not all code is life threatening in worst case scenario. Better comparison would be "would you like to be served by first time waiter or rather expert one?". In most cases it doesn't matter, and when it does, the price point of the service is significantly higher.
- Dah00n 5y ago
  This is mostly just a rant not directed at you but on the state of software... The Colonial Pipeline ransomware wasn't life threatening. These things happen because of bad* developers and zero accountability from developers over publishers to software owners. As it is now pretty much all commercial software is "first time waiter" quality. Granted it isn't all on the actual developers but on the whole pipeline(!). Most software is on the "let's use an anchor to stop our newly developed car because we have used anchors for decades and understand them better than drum brakes" level of quality. * Bad code because of a lack of understanding and/or time constraints. But developers don't mind coding bad code (not enough to refuse at least). Developers need to be more like doctors and engineers. Accountability and proven skill matters and would force managements hand like at hospitals and building projects.
  - gombosg 5y ago
    I'd like to add that modern agile IT environments are different than that of traditional engineering. We aim for fast MVPs, fast iterations, "failing fast", "moving fast", "delivering value quickly", generally preferring speed over quality, agility over "waterfall" planning, continuous delivery over batched releases and, well, often accruing tech debt over shipping features later. One can argue that "fail fast" should not be about code & feature quality but rather about determining proper scope, splitting features sensibly etc. But then we still have deadlines to meet and code quality suffers. What I'm saying that this kind of fast-moving environment actively discourages traditional (like doctors & civil engineers) engineering practices. You might have lots of (unit|integration|E2E) tests but the company may miss practices like proper security reviews and code won't be reviewed, tested and approved by multiple people like, say, bridge building plans are. This problem mostly comes up not with your usual web app but when critical systems are affected (like in the aerospace industry or industrial systems). But through supply chain attacks, nearly any system can be vulnerable these days. We should definitely have better regulation on how software is made.
    - wongarsu 5y ago
      The problem with the waterfall model is that it only works if you can determine the requirements up front and they stay fairly static. Sometimes that's true, but all too often its impossible. But iterative development and fail-fast are independent of quality. If a company skips security reviews and is fine with technical debt because "it works, just ship it", what makes you think they would do security reviews or care about better-than-minimum code quality when following a waterfall system
  - runawaybottle 5y ago
    Bad code is happening for non-malicious reasons. I’ll suggest these two being the main factors, and I’ll concede that it is conjecture, but I’m drawn to these two since I assume good-faith amongst all actors: 1) Everyone needs to pump out all of their bad code before they get to their decent code. Imagine your lifetime array of code, it will look like this [bad, bad, ...(lots of bad), bad, good, bad, good, good, ...(lots of good), good]. As you can see, you’ll have to pop (poop) all the bad out before you get to good. Some people have a smaller length array due to other factors (talent), but even so, there is bad in front of the array. What are the implications of this? That should be obvious. This industry hires people straight out of college or people in their mid 20s to be project leads. You do the math. 2) Lack of suffering. Many people haven’t had to toil in someone else’s codebase. Many people are given green-field projects that are scrapped quickly, at which point the business (or another business) gives a brand new project. Constantly building shit from scratch by yourself means you don’t understand pain. Go work in someone else’s garbage app to feel pain. Then you will rethink what good code is. Good code is not painful, and the definition of ‘not painful’ will be obvious to the survivors of pain. Solution: Continue to crap out your bad code in non impactful areas of the codebase and avoid crapping in critical parts. You have to crap somewhere, and that is understandable. Lastly, don’t turn down the experience of working in someone else’s labyrinth. The experience is valuable.
- ptx 5y ago
  I once experienced a waiter holding raw meat (to be cooked at the table) over the drinks while serving, unknowingly letting it drip into the glass. (But as I didn't want to find out if it would life-threatening or not, I didn't try the drink.)
  - pkdpic_y9k 5y ago
    This one time I had a waiter who it turned out wasn't even our waiter and we gave him our money and the food was good but where did he get the food? Also there are some great thoughts in this thread on why there is such a shocking amount of spaghetti code out there and I like the ransomware note also. Thought provoking. Too bad I'm such a terrible programmer.
- jackcviers3 5y ago
  I hate to do this, but: Stop equating programming and bus drivers or waiters. They aren't equal. Programming is difficult in its depth and breadth in a way that waiting tables is not. Stop treating all programming tasks as equal. They are not. Most of the easy ones are only easy because they run on top of all the difficult programs. That is the goal of the difficult programs, to make it possible for laymen to do work that would require an expert for certain repetitive tasks if the underlying program did not exist. Most people would not be capable of getting Hello World to run without the OS and high-level abstractions that take expertise to develop. And making that possible requires many many experts in many different kinds of programming. Stepping off of the single thread and single machine model into concurrent and distributed computing to enable even more laymen to make stuff takes even more experts. There is a meme in the industry that people shouldn't strive for expertise. We still need more experts, and you become an expert through practice while still a layman. Nothing would be worse off if we had more experts capable of deciding when to use something extensible off of the shelf to enable laymen to do simple tasks, and when to build a platform to eventually enable that task to be done by a layman. A lot of things would be worse off if we encouraged all people to stop at the layman level. We should encourage everyone to at least become a layman for their own enrichment. But we should also encourage laymen to strive for expertise to lower the barriers to entry to produce more laymen capable of doing simple tasks.
Zababa 5y ago
> Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by an architect who knows just enough to complete the job and does not care a bit for more? I don't think this part is useful. If you're writing directly code for an application you don't usually need to be the best, and your errors can be handled by layers of supervision/QA. If you're writing internal libraries and tools, you need to be a better programmer. If you're in one of the let's say Rust compiler groups, you will need to really know your stuff. But even the Rust compiler has issues for newcommers that aren't too hard. I don't think comparing software engineering to bus drivers and bridge architects leads to useful insight. I do agree with the rest of your post though. A part of my day job is to develop and maintain applications made by people that didn't/couldn't program "properly" (shadow IT). Everything more or less work and the end users are satisfied, but I often fear that one day something will depend on one of those applications. On the other hand taking the time to do everything "properly" would lead to a lot less experimentations and/or use a lot more resources. It's hard to find a good balance.
- graphtrader 5y ago
  I have always assumed many programmers are terrible at sports in general so they turn programming into this weird sport of who can be the Cristiano Ronaldo of programming.
  - Zababa 5y ago
    That's a pretty unfair way to put it. People that do "too much" to try to impress their collegues or themselves exist everywhere. You can see it in some people's code, you can see it in the way some people dress, you can see it in some powerpoint presentations, you can see it in sports.
lordnacho 5y ago
How often do you check your surgeon's grades? Or any of those things you mention? I normally just trust that the bus company has hired a guy with a license.
- akiselev 5y ago
  When people say driver license, they mean the one kids can get at age 16. Driving a bus requires a commercial driver license, which is referred to as a CDL - it's a much more rigorous test. How often are you driven around by bus drivers who just finished their learner's permit?
dahart 5y ago
> This mindset is how we end up with layers upon layers of badly designed and buggy software that underpins almost every aspect of modern life. No, it’s not. Changing requirements by adding features is by far the biggest cause of badly designed and buggy software. I’ve worked on multiple teams where everyone was fully committed and highly skilled, and it didn’t magically fix the problems of software. It wasn’t any better than working on teams of people who were less interested. Our inability to stop adding features is what kills us, and this inability is actually stronger with people who think they’ve ‘mastered’ the art of programming than with people who can finish a one-off task. > they will probably not be a general purpose solution of the problem at hand Ironically, perhaps, in my decades of professional programming, the number one biggest waste of money I’ve seen is people over-engineering something under the banner of making something “general purpose” that didn’t need to be. I’ve watched a couple of different teams of very smart people waste literally tens of millions of dollars by deciding to rewrite something that didn’t need rewriting, and dramatically overestimate their ability to finish it in a reasonable amount of time and avoid the same mistakes they made the first time. > If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum. This sounds good in theory, but is specious. The real way to get high quality software is to define what that means and stick to it ruthlessly. You don’t need to know a lot about programming. You need a management that is okay lengthening schedules to make room for testing. You need a CEO who is okay with saying no to customer demands for features that the competition has. You need programmers who know when to stop programming and when to avoid rationalizing their ‘general purpose’ solution that solves problems that don’t actually exist. Good luck in your search for high quality software, it’s very very difficult to find a team who can commit to it, and there are good reasons why: it’s extremely expensive.
- xupybd 5y ago
  I would even say that good code is not always in a businesses best interests. The business needs to change quickly and cheaply. So they rack up technical debt. Often getting away with it for decades. The developers suffer through it but the CEOs walk away with more money in their pockets.
  - 5y ago

Yiin 5y ago

not all code is life threatening in worst case scenario. Better comparison would be "would you like to be served by first time waiter or rather expert one?". In most cases it doesn't matter, and when it does, the price point of the service is significantly higher.

Dah00n 5y ago
This is mostly just a rant not directed at you but on the state of software... The Colonial Pipeline ransomware wasn't life threatening. These things happen because of bad* developers and zero accountability from developers over publishers to software owners. As it is now pretty much all commercial software is "first time waiter" quality. Granted it isn't all on the actual developers but on the whole pipeline(!). Most software is on the "let's use an anchor to stop our newly developed car because we have used anchors for decades and understand them better than drum brakes" level of quality. * Bad code because of a lack of understanding and/or time constraints. But developers don't mind coding bad code (not enough to refuse at least). Developers need to be more like doctors and engineers. Accountability and proven skill matters and would force managements hand like at hospitals and building projects.
- gombosg 5y ago
  I'd like to add that modern agile IT environments are different than that of traditional engineering. We aim for fast MVPs, fast iterations, "failing fast", "moving fast", "delivering value quickly", generally preferring speed over quality, agility over "waterfall" planning, continuous delivery over batched releases and, well, often accruing tech debt over shipping features later. One can argue that "fail fast" should not be about code & feature quality but rather about determining proper scope, splitting features sensibly etc. But then we still have deadlines to meet and code quality suffers. What I'm saying that this kind of fast-moving environment actively discourages traditional (like doctors & civil engineers) engineering practices. You might have lots of (unit|integration|E2E) tests but the company may miss practices like proper security reviews and code won't be reviewed, tested and approved by multiple people like, say, bridge building plans are. This problem mostly comes up not with your usual web app but when critical systems are affected (like in the aerospace industry or industrial systems). But through supply chain attacks, nearly any system can be vulnerable these days. We should definitely have better regulation on how software is made.
  - wongarsu 5y ago
    The problem with the waterfall model is that it only works if you can determine the requirements up front and they stay fairly static. Sometimes that's true, but all too often its impossible. But iterative development and fail-fast are independent of quality. If a company skips security reviews and is fine with technical debt because "it works, just ship it", what makes you think they would do security reviews or care about better-than-minimum code quality when following a waterfall system
- runawaybottle 5y ago
  Bad code is happening for non-malicious reasons. I’ll suggest these two being the main factors, and I’ll concede that it is conjecture, but I’m drawn to these two since I assume good-faith amongst all actors: 1) Everyone needs to pump out all of their bad code before they get to their decent code. Imagine your lifetime array of code, it will look like this [bad, bad, ...(lots of bad), bad, good, bad, good, good, ...(lots of good), good]. As you can see, you’ll have to pop (poop) all the bad out before you get to good. Some people have a smaller length array due to other factors (talent), but even so, there is bad in front of the array. What are the implications of this? That should be obvious. This industry hires people straight out of college or people in their mid 20s to be project leads. You do the math. 2) Lack of suffering. Many people haven’t had to toil in someone else’s codebase. Many people are given green-field projects that are scrapped quickly, at which point the business (or another business) gives a brand new project. Constantly building shit from scratch by yourself means you don’t understand pain. Go work in someone else’s garbage app to feel pain. Then you will rethink what good code is. Good code is not painful, and the definition of ‘not painful’ will be obvious to the survivors of pain. Solution: Continue to crap out your bad code in non impactful areas of the codebase and avoid crapping in critical parts. You have to crap somewhere, and that is understandable. Lastly, don’t turn down the experience of working in someone else’s labyrinth. The experience is valuable.
ptx 5y ago
I once experienced a waiter holding raw meat (to be cooked at the table) over the drinks while serving, unknowingly letting it drip into the glass. (But as I didn't want to find out if it would life-threatening or not, I didn't try the drink.)
- pkdpic_y9k 5y ago
  This one time I had a waiter who it turned out wasn't even our waiter and we gave him our money and the food was good but where did he get the food? Also there are some great thoughts in this thread on why there is such a shocking amount of spaghetti code out there and I like the ransomware note also. Thought provoking. Too bad I'm such a terrible programmer.
jackcviers3 5y ago
I hate to do this, but: Stop equating programming and bus drivers or waiters. They aren't equal. Programming is difficult in its depth and breadth in a way that waiting tables is not. Stop treating all programming tasks as equal. They are not. Most of the easy ones are only easy because they run on top of all the difficult programs. That is the goal of the difficult programs, to make it possible for laymen to do work that would require an expert for certain repetitive tasks if the underlying program did not exist. Most people would not be capable of getting Hello World to run without the OS and high-level abstractions that take expertise to develop. And making that possible requires many many experts in many different kinds of programming. Stepping off of the single thread and single machine model into concurrent and distributed computing to enable even more laymen to make stuff takes even more experts. There is a meme in the industry that people shouldn't strive for expertise. We still need more experts, and you become an expert through practice while still a layman. Nothing would be worse off if we had more experts capable of deciding when to use something extensible off of the shelf to enable laymen to do simple tasks, and when to build a platform to eventually enable that task to be done by a layman. A lot of things would be worse off if we encouraged all people to stop at the layman level. We should encourage everyone to at least become a layman for their own enrichment. But we should also encourage laymen to strive for expertise to lower the barriers to entry to produce more laymen capable of doing simple tasks.

Zababa 5y ago

> Just apply the same reasoning to other areas: Would you want to drive in a bus with a bus driver who just barely got his driver's license? Would you want to use a bridge designed by an architect who knows just enough to complete the job and does not care a bit for more? I don't think this part is useful. If you're writing directly code for an application you don't usually need to be the best, and your errors can be handled by layers of supervision/QA. If you're writing internal libraries and tools, you need to be a better programmer. If you're in one of the let's say Rust compiler groups, you will need to really know your stuff. But even the Rust compiler has issues for newcommers that aren't too hard. I don't think comparing software engineering to bus drivers and bridge architects leads to useful insight. I do agree with the rest of your post though. A part of my day job is to develop and maintain applications made by people that didn't/couldn't program "properly" (shadow IT). Everything more or less work and the end users are satisfied, but I often fear that one day something will depend on one of those applications. On the other hand taking the time to do everything "properly" would lead to a lot less experimentations and/or use a lot more resources. It's hard to find a good balance.

graphtrader 5y ago
I have always assumed many programmers are terrible at sports in general so they turn programming into this weird sport of who can be the Cristiano Ronaldo of programming.
- Zababa 5y ago
  That's a pretty unfair way to put it. People that do "too much" to try to impress their collegues or themselves exist everywhere. You can see it in some people's code, you can see it in the way some people dress, you can see it in some powerpoint presentations, you can see it in sports.

lordnacho 5y ago

How often do you check your surgeon's grades? Or any of those things you mention? I normally just trust that the bus company has hired a guy with a license.

akiselev 5y ago
When people say driver license, they mean the one kids can get at age 16. Driving a bus requires a commercial driver license, which is referred to as a CDL - it's a much more rigorous test. How often are you driven around by bus drivers who just finished their learner's permit?

dahart 5y ago

> This mindset is how we end up with layers upon layers of badly designed and buggy software that underpins almost every aspect of modern life. No, it’s not. Changing requirements by adding features is by far the biggest cause of badly designed and buggy software. I’ve worked on multiple teams where everyone was fully committed and highly skilled, and it didn’t magically fix the problems of software. It wasn’t any better than working on teams of people who were less interested. Our inability to stop adding features is what kills us, and this inability is actually stronger with people who think they’ve ‘mastered’ the art of programming than with people who can finish a one-off task. > they will probably not be a general purpose solution of the problem at hand Ironically, perhaps, in my decades of professional programming, the number one biggest waste of money I’ve seen is people over-engineering something under the banner of making something “general purpose” that didn’t need to be. I’ve watched a couple of different teams of very smart people waste literally tens of millions of dollars by deciding to rewrite something that didn’t need rewriting, and dramatically overestimate their ability to finish it in a reasonable amount of time and avoid the same mistakes they made the first time. > If you want to write dependable, high-quality, maintainable, reusable software you better know more than the bare minimum. This sounds good in theory, but is specious. The real way to get high quality software is to define what that means and stick to it ruthlessly. You don’t need to know a lot about programming. You need a management that is okay lengthening schedules to make room for testing. You need a CEO who is okay with saying no to customer demands for features that the competition has. You need programmers who know when to stop programming and when to avoid rationalizing their ‘general purpose’ solution that solves problems that don’t actually exist. Good luck in your search for high quality software, it’s very very difficult to find a team who can commit to it, and there are good reasons why: it’s extremely expensive.

xupybd 5y ago
I would even say that good code is not always in a businesses best interests. The business needs to change quickly and cheaply. So they rack up technical debt. Often getting away with it for decades. The developers suffer through it but the CEOs walk away with more money in their pockets.
- 5y ago