5 ms·

I feel like there is an unfair sentiment of competence elitism in the software engineering world. I don't think you can stop less experienced engineers (or exp

I feel like there is an unfair sentiment of competence elitism in the software engineering world. I don't think you can stop less experienced engineers (or experienced but still bad engineers) from contributing to projects - especially at the scale of a lot of these large organisations. After all, for people early in their careers, being bad is the first step to being good and it's impractical (or impossible) for organisations to exclusively hire "premium" engineers. There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today. Project architects should instead strive to design their systems such that they expect low quality contributions and limit the potential damage those contributions can have. Systems should be able to take a low quality contributions and if the need arises, have the capacity for those circuits to be optimised at a later date without rewriting the entire thing. I personally find the argument that "bad engineers make microservices bad" to be silly. Bad engineers would poison any poorly architected project, be it a monolith, microservice or otherwise. Microservices are just an architectural optimisation with trade offs that some organisations find value in.

PH95VuimJjqBqy 3y ago
they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes. Except in our industry. In our industry the juniors often are the ones making the decisions.
- ryanmcgarvey 3y ago
  That's the problem with software - it's decisions all the way down. Outside of prototyping, there's very little "work" to be done that doesn't contain some kind of systems decision.
  - calvinmorrison 3y ago
    this can be limited though. I just went through refactoring a whole set of classes that implement the same interface, but it was not defined as an Interface. now any new class that implements this _must_ meet at least some expectations, enforced by the code. So in one way, OOP is great for limiting side effects.
- wutwutwat 3y ago
  Sorry that you've worked for some horrible companies. What you described has not been my experience over the last 10+ years at some rather large and now public tech companies. Part of a Senior's job duties are to mentor Juniors and most job descriptions explicitly list that as an expectation of the Senior role.
  - PH95VuimJjqBqy 3y ago
    I'm unsure as to how that disagrees with what I said.
    - wutwutwat 3y ago
      > they're called juniors and every other industry has seniors to help guide them > Except in our industry
      - PH95VuimJjqBqy 3y ago
        here's what was actually said without the cherry picking > Except in our industry. In our industry the juniors OFTEN are try again.
        wutwutwat 3y ago
        Often make the decisions. I’m talking about mentoring. Which is what my first comment was specifically mentioning. Which was in response to the parent comment saying mentoring didn’t happen.
        PH95VuimJjqBqy 3y ago
        the implication of your words here is that you think juniors make decisions while seniors mentor them? I suppose for some implication is difficult to deal with so let me be explicit. there often are no seniors. A junior mentoring has another phrase. The blind leading the blind.
- gonzo41 3y ago
  Building construction has been going on for ~thousands of years now. Buildings still fall down. The IT industry is doing remarkably well for its first 70 years.
  - PH95VuimJjqBqy 3y ago
    it's not normal for buildings to fall down, they're usually purposefully pulled down. In the US buildings have to adhere to legal specifications specifically to ensure that doesn't happen.
fallingknife 3y ago
Inexperienced engineers aren't the problem. Juniors will submit spaghetti code messes, but those can be cleaned up without too much trouble. The real problem is incompetent people higher up that can make large scale architecture and design decisions. e.g. somewhere I used to work there was a VP that decided to hand roll an ORM instead of just using Django.
drewcoo 3y ago
> I feel like there is an unfair sentiment of competence elitism in the software engineering world. And I feel like there are people in software that complain about things like "competence elitism" when other industries encourage doing things right. Take actual engineers, for example: https://www.nspe.org/resources/ethics/code-ethics/engineers-creed https://www.nspe.org/resources/ethics/code-ethics/engineers-...
- apatheticonion 3y ago
  I'm all for raising the bar of engineering standards though realistically enforcing that would be a significant logistical challenge. Consider that there are varying levels of competence required for the different problems in software - for instance someone writing code for medical equipment requires a different type and level of expertise than someone writing a website for a small business. Consider how many YouTubers and blog posts are out there giving bad advice. Consider how easy it is to get started but also how many niches there are with differing skill sets required by each niche. Perhaps we could implement a "bar" exam for programmers - however for which niche would it apply? How many different exams would need to be drawn up? By whom and how would this be coordinated internationally? Does this apply to esoteric segments like Excel or jobs that rely on basic scripting like bash/powershell/SQL/Python? Would we need to restrict people from giving advice on platforms like YouTube through a licensing system? - much like how it's illegal to give financial advice online without a license in some countries. It would be nice but I do think that it's extremely ambitious. I struggle to see how it could be implemented inside of a decade long time frame.
hu3 3y ago
I've seen clients run automated architecture tests with varying degrees of success. These reduce damage done by juniors. For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer). Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions. That's the gist of it.
- zx8080 3y ago
  > damage done by juniors This phrase says it all. But why doesn't the review process help to improve the quality?
  - hu3 3y ago
    Some clients do use Pull Request reviews. And to a lesser extent some use Pair Programming. Automated architecture tests helps to keep things tidy during those rushed moments.
    - zx8080 3y ago
      > Automated architecture tests Is there some good links to know more about it?
      - hu3 3y ago
        Hi zx, I'll link some tools I've seen and/or worked with: For C#: 1) https://github.com/TNG/ArchUnitNET https://github.com/TNG/ArchUnitNET For PHP: 1) Pest testing framework demonstration: https://youtu.be/ZidLP7TqXnc?t=133 https://youtu.be/ZidLP7TqXnc?t=133 2) https://github.com/spaze/phpstan-disallowed-calls https://github.com/spaze/phpstan-disallowed-calls 3) https://github.com/ekino/phpstan-banned-code https://github.com/ekino/phpstan-banned-code 4) https://packagist.org/packages/ta-tikoma/phpunit-architecture-test https://packagist.org/packages/ta-tikoma/phpunit-architectur... 5) https://qossmic.github.io/deptrac/ https://qossmic.github.io/deptrac/ Hope that helps.
sublinear 3y ago
> There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today. I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence. Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.
rstephenson2 3y ago
This sounds in line with Google creating go: restrict the language features so you can hire mass quantities of programmers and be reasonably sure they won’t go off the rails. It’s fine for what it’s for but doesn’t seem like that should be the goal of most programming projects? Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)
- sokoloff 3y ago
  I think AI copilots will allow more people to be productive in software and, by so doing, allow vastly more software to be created. Related to that idea is that, with the right definition (unconventional but not tortured), I think that more software is created in Excel than in python today and a large swath of the people making spreadsheets today for their business will be using AI copilots to make better software 20 years from now.
  - rstephenson2 3y ago
    Totally agree. AI empowers people with existing software expertise, and empowers people with domain knowledge. Both of which have historically been bottlenecked by things AI is now getting good at.
Nondv 3y ago
I'm sorry if it came across this way. It was definitely not intentional! My opinions perfectly match yours, in fact :) I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :) I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.

PH95VuimJjqBqy 3y ago

they're called juniors and every other industry has seniors to help guide them and ensure they don't make major mistakes. Except in our industry. In our industry the juniors often are the ones making the decisions.

ryanmcgarvey 3y ago
That's the problem with software - it's decisions all the way down. Outside of prototyping, there's very little "work" to be done that doesn't contain some kind of systems decision.
- calvinmorrison 3y ago
  this can be limited though. I just went through refactoring a whole set of classes that implement the same interface, but it was not defined as an Interface. now any new class that implements this _must_ meet at least some expectations, enforced by the code. So in one way, OOP is great for limiting side effects.
wutwutwat 3y ago
Sorry that you've worked for some horrible companies. What you described has not been my experience over the last 10+ years at some rather large and now public tech companies. Part of a Senior's job duties are to mentor Juniors and most job descriptions explicitly list that as an expectation of the Senior role.
- PH95VuimJjqBqy 3y ago
  I'm unsure as to how that disagrees with what I said.
  - wutwutwat 3y ago
    > they're called juniors and every other industry has seniors to help guide them > Except in our industry
    - PH95VuimJjqBqy 3y ago
      here's what was actually said without the cherry picking > Except in our industry. In our industry the juniors OFTEN are try again.
      - wutwutwat 3y ago
        Often make the decisions. I’m talking about mentoring. Which is what my first comment was specifically mentioning. Which was in response to the parent comment saying mentoring didn’t happen.
        PH95VuimJjqBqy 3y ago
        the implication of your words here is that you think juniors make decisions while seniors mentor them? I suppose for some implication is difficult to deal with so let me be explicit. there often are no seniors. A junior mentoring has another phrase. The blind leading the blind.
gonzo41 3y ago
Building construction has been going on for ~thousands of years now. Buildings still fall down. The IT industry is doing remarkably well for its first 70 years.
- PH95VuimJjqBqy 3y ago
  it's not normal for buildings to fall down, they're usually purposefully pulled down. In the US buildings have to adhere to legal specifications specifically to ensure that doesn't happen.

fallingknife 3y ago

Inexperienced engineers aren't the problem. Juniors will submit spaghetti code messes, but those can be cleaned up without too much trouble. The real problem is incompetent people higher up that can make large scale architecture and design decisions. e.g. somewhere I used to work there was a VP that decided to hand roll an ORM instead of just using Django.

drewcoo 3y ago

> I feel like there is an unfair sentiment of competence elitism in the software engineering world. And I feel like there are people in software that complain about things like "competence elitism" when other industries encourage doing things right. Take actual engineers, for example: https://www.nspe.org/resources/ethics/code-ethics/engineers-creed https://www.nspe.org/resources/ethics/code-ethics/engineers-...

apatheticonion 3y ago
I'm all for raising the bar of engineering standards though realistically enforcing that would be a significant logistical challenge. Consider that there are varying levels of competence required for the different problems in software - for instance someone writing code for medical equipment requires a different type and level of expertise than someone writing a website for a small business. Consider how many YouTubers and blog posts are out there giving bad advice. Consider how easy it is to get started but also how many niches there are with differing skill sets required by each niche. Perhaps we could implement a "bar" exam for programmers - however for which niche would it apply? How many different exams would need to be drawn up? By whom and how would this be coordinated internationally? Does this apply to esoteric segments like Excel or jobs that rely on basic scripting like bash/powershell/SQL/Python? Would we need to restrict people from giving advice on platforms like YouTube through a licensing system? - much like how it's illegal to give financial advice online without a license in some countries. It would be nice but I do think that it's extremely ambitious. I struggle to see how it could be implemented inside of a decade long time frame.

hu3 3y ago

I've seen clients run automated architecture tests with varying degrees of success. These reduce damage done by juniors. For example tests that ensure that controller actions don't create SQL queries directly but instead always use repositories/services/models (whatever you call data fetching layer). Another example is a test that ensures that there's no "print" in data fetching layer, only allowing them in HTTP controller actions. That's the gist of it.

zx8080 3y ago
> damage done by juniors This phrase says it all. But why doesn't the review process help to improve the quality?
- hu3 3y ago
  Some clients do use Pull Request reviews. And to a lesser extent some use Pair Programming. Automated architecture tests helps to keep things tidy during those rushed moments.
  - zx8080 3y ago
    > Automated architecture tests Is there some good links to know more about it?
    - hu3 3y ago
      Hi zx, I'll link some tools I've seen and/or worked with: For C#: 1) https://github.com/TNG/ArchUnitNET https://github.com/TNG/ArchUnitNET For PHP: 1) Pest testing framework demonstration: https://youtu.be/ZidLP7TqXnc?t=133 https://youtu.be/ZidLP7TqXnc?t=133 2) https://github.com/spaze/phpstan-disallowed-calls https://github.com/spaze/phpstan-disallowed-calls 3) https://github.com/ekino/phpstan-banned-code https://github.com/ekino/phpstan-banned-code 4) https://packagist.org/packages/ta-tikoma/phpunit-architecture-test https://packagist.org/packages/ta-tikoma/phpunit-architectur... 5) https://qossmic.github.io/deptrac/ https://qossmic.github.io/deptrac/ Hope that helps.

sublinear 3y ago

> There's also nothing wrong with engineers who program exclusively to collect a paycheck and aren't actually passionate about their work. I believe this is an inevitable side effect of the accessibility of programming today. I only agree if the person who lacks passion can actually do the job and has experience. The trouble with programming computers is that you cannot get sloppy with the implementation details or design decisions. It is absolutely not a field accessible to people who guess too much and code by coincidence. Often those details are also overlooked at the project planning level so it's unfair to everyone else who has to pick up their slack. It's already bad enough that the people in charge usually don't understand the project very well.

rstephenson2 3y ago

This sounds in line with Google creating go: restrict the language features so you can hire mass quantities of programmers and be reasonably sure they won’t go off the rails. It’s fine for what it’s for but doesn’t seem like that should be the goal of most programming projects? Especially with AI copilots getting better, it feels like we’re headed for a point where you’re either capable of architecting complex systems, or there isn’t much software for you to write: other industries tend to have rote work for beginners while they gain skills, but in software rote work tends to get automated away. AI can help people learn faster, but given what AI has proven good at, I expect more of the gains will go to expert productivity. (or non-programmer domain experts)

sokoloff 3y ago
I think AI copilots will allow more people to be productive in software and, by so doing, allow vastly more software to be created. Related to that idea is that, with the right definition (unconventional but not tortured), I think that more software is created in Excel than in python today and a large swath of the people making spreadsheets today for their business will be using AI copilots to make better software 20 years from now.
- rstephenson2 3y ago
  Totally agree. AI empowers people with existing software expertise, and empowers people with domain knowledge. Both of which have historically been bottlenecked by things AI is now getting good at.

Nondv 3y ago

I'm sorry if it came across this way. It was definitely not intentional! My opinions perfectly match yours, in fact :) I did try to point out that I don't really blame normal devs but the leadership instead. A fish rots from the head. My writing skills are just not that good (yet) :) I also used "incompetence" very broadly which was probably a mistake from writing perspective. From bad management decisions all the way to brilliant engineers simply not being familiar with a particular technology/paradigm.