35 ms·

You should first establish yourself as a productive member of the team. No one is going to want to hear about how they could do things better from someone who j

You should first establish yourself as a productive member of the team. No one is going to want to hear about how they could do things better from someone who just started. Once you have credibility and maybe some allies you'll want to have some evidence to support any new processes or workflows. Anecdotes about how you did things at other jobs won't carry a lot of weight. The problem with software development techniques and tools like automated testing and style guides is that while they look like good ideas, and work at some places, there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. Programmers usually perceive any new code base as crap in desperate need of new ideas and tools. It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense.

throwaway8365 5y ago
Totally agree with all your points except >there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. If you'd have said "there aren't any published papers _proving_ this" I would've agreed simply because I do not know if such studies exist or not (they might); but I'd argue that automated tests obviously improve code quality and productivity. And also ramp up time, which is important in fast growing teams (my case).
- kqr 5y ago
  The question that matters is not whether automated tests improve code quality and productivity. The question that needs to be answered is "if I took the time I previously spent on automated testing, and instead spent it on something else like code review or design review, would that result in greater code quality and productivity than automated testing did?" And phrased that way, you see it's not a dichotomy. It depends on what you would spend the time on instead of automated testing. It depends on whether you already had peer review in your process. It depends on what sort of automated tests you spend time on. It's very hard to say something general without those details. ---- Note that I'm not taking a stance against automated testing. I prefer working in a test-first style myself. I'm just saying it's not that simple.
- hoten 5y ago
  It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change. How do they know nothing broke? If there are no tests, they must spend an inordinate amount of time learning the entire system / product to gain any confidence they didn't break something, only to likely miss something that a senior team member will point out. The back/forth will take multiple developers time. At worst, it gets punted all the way to a QA team. Could be days. Or, with tests, that happens far less often and the feedback loop can be more like 10 minutes. Of course, tests don't solve onboarding, but they provide nice guard rails.
  - dboreham 5y ago
    This assumes the tests are mostly valid. My experience in recent years has been that they won't be.
    - hoten 5y ago
      Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort because the original claim had no qualifiers, and was suggesting that any version of automated tests are orthogonal to developer productivity. All you must do to refute that is think of any codebase you were able to make progress on faster because a test told you what was wrong faster than it'd take you to blame source code and send an email to a developer you maybe have never met yet.
      - toast0 5y ago
        > Of course I'm assuming useful tests, why wouldn't I? Because useful tests seem pretty hard to have in practice. Especially when starting testing for a project without tests and a team without testing experience. Early testing reduces productivity, and the proposed gains may never develop.
- jiggawatts 5y ago
  I'm replying to this and also some of the sibling comments. No, automated development-time tests do not necessarily equate to higher quality, given that they: - Take time away from other activities - May provide a false positive, lulling developers into a false sense of confidence - Increase the time taken for certain CI/CD operations, sometimes by hours or days! - The presence of a large volume of "test" code means that certain refactoring operations take a lot longer, which is a real cost. People go into some work environments where tests DID help, and they generalise that to ALL work environments. Automated build-time tests are less important, and entire categories may be potentially unnecessary when: - The product is written in a strongly-typed language that catches most errors at compile time. - If high-level "linting" tools are used to further enhance the code quality before the executable ever runs. - If feedback from the production environment is more relevant. E.g.: for web applications with performance issues being monitored by an APM, but no critical code stability concerns at build time. Think typical web apps with no real consequences to a crash, not finance applications where a small error could mean Real Money. - Where time-to-market is more important than chasing 100% robustness at the expense of meeting release dates. You often see people from a PHP or Python background go on and on about the importance of tests, but those are dynamically typed languages with lots of unexpected pitfalls that only testing will uncover. Meanwhile entire teams do just fine without any automated tests when using languages like C#, Java, or Rust.
  - cweagans 5y ago
    Types do a great job at assuring you’re getting generally the right kind of data in and out of different functions/methods, but they don’t assure that the program is actually doing the right thing. Strong typing just helps to assure that the program isn’t doing specific categories of the wrong thing (in the same way that Rust and Go make it difficult to write memory-unsafe code). I mean, Go and Rust both have testing capabilities built in. If it wasn’t necessary, why would they do that? Beyond the most trivial of projects, I can’t think of a single project that I’ve worked on (or even looked at on GitHub) that has weighed the costs and benefits of automated testing and decided it just wasn’t worth it.
    - jiggawatts 5y ago
- itsdrewmiller 5y ago
  Generally speaking "empirical evidence" means "published papers", with a little bit of flex for preprints or trustworthy-but-not-peer-reviewed experimental findings.
  - gregjor 5y ago
    I was using it to mean actual data rather than anecdotes. The subject of programmer productivity is both much-studied and discussed and very hard to define, measure, and compare. The studies that do have some empirical evidence seem to show that team dynamics and individual programmer personalities have the most dramatic effects, compared to things like programming language, tests, style guides, etc. It's not that consistent styles and automated testing are bad ideas, it's that they don't clearly make a big dent in team productivity in cases where one or a few incompetent (or merely slow) programmers, or one jerk, can derail everyone's productivity. This I why I emphasized demonstrating a commitment to the team and showing some contributions before criticizing the environment and trying to propose changes. If you want the project to grind to a halt tell your new co-workers they are doing everything wrong. No automated test suite is going to fix that problem.
- gregjor 5y ago
  I think you are agreeing with me. There's anecdotal evidence like you offer. It's not necessarily obvious to everyone that automated tests improve code quality or it would be a settled issue (it's not). In my own career (40+ years) I have worked with automated testing and TDD, and without, and I can't say that TDD "obviously" improves code quality. I know other professional programmers who have that experience. Like everything else in software development it's probably situational and depends on the individuals and the team.
tayo42 5y ago
> No one is going to want to hear about how they could do things better from someone who just started I don't understand why more people don't get this. Like thanks for showing up and implying everyone is incompetent with your suggestions?
- themitigating 5y ago
  You shouldn't judge quality or suggestions by seniority
  - givemeethekeys 5y ago
    It's not seniority that's the criteria. It's street cred / rapport.
  - msh 5y ago
    It's not seniority, it's someone showing up who don't understand the challenges that lead to the current situation and not learning them before pointing at issues.
- colechristensen 5y ago
  It gets even worse when somebody is successful in being the new guy not understanding the new codebase and making big changes to recreate their previous workspace anyway. Fresh eyes and a fresh perspective are useful but don’t go recreating the universe right away.
- gregjor 5y ago
  Lack of humility kind of plagues our profession.
dehrmann 5y ago
> It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense. Classic Stockholm Syndrome.
- beckingz 5y ago
  Some call it stockholm syndrome, we call it the Spotify model!
  - dehrmann 5y ago
    Probably should mention I'm an ex-Spotifier.
- gregjor 5y ago
  That's one way to look at it. When you put a bunch of smart people together on a team they all tend to think they're right and they can get very passionate, even when they don't have any data or measurements to back up their opinions. A little humility and time spent adapting to the environment, team, and code base can go a long way. Anecdotally my experience is that most programmers react to almost all code they didn't write as if it was crap. The more code they have to read and understand the more likely they are to complain about the quality of the code and the overall design of the system. Imagine someone looking at a photo of your house and telling you a hundred things wrong with it, without stepping foot inside or spending some time living there.
dehrmann 5y ago
One thing that can help build credibility before making larger suggestions is working on obvious, uncontroversial pain points in any spare time you have.
noufalibrahim 5y ago
This is an excellent observation. Thank you for making this. A pre requisite for "convincing" a large team is respect from the team. Assuming that it's not a toxic jungle, proven competence over a period of time is a good way of of earning said respect. Once you have that, you can cash it in for attention and people will listen. A more tactical thing is to actually do some work. You said that they don't have a style guide. Create one which you personally use and share it with your immediate team so that your own lives are better. Your immediate manager and team mates will have to work with you and if you start doing things which make your work obviously better, they'll pick up and that will give you mileage in the long run. Automated testing is hard in practice when there are a lot of external dependencies and when there's a huge legacy codebase. This is a case by case thing but just like before, if you have something to show and the respect to buy attention, you might be able to sell an idea to them.
- gregjor 5y ago
  "Show, don't tell" is a good principle. Don't tell the team how they should write better code. Show them an example that you can credibly argue represents improvement. Expect pushback and alternate opinions, don't fall in love with your particular style. Teams can get derailed over very minor things like tabs vs. spaces, so remember the important thing is a consistent style, not a particular style. Automated tests can be useful but don't expect the team to retrofit that, or for everyone to buy into it. You have to show the benefits in that environment.

throwaway8365 5y ago

Totally agree with all your points except >there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality. If you'd have said "there aren't any published papers _proving_ this" I would've agreed simply because I do not know if such studies exist or not (they might); but I'd argue that automated tests obviously improve code quality and productivity. And also ramp up time, which is important in fast growing teams (my case).

kqr 5y ago
The question that matters is not whether automated tests improve code quality and productivity. The question that needs to be answered is "if I took the time I previously spent on automated testing, and instead spent it on something else like code review or design review, would that result in greater code quality and productivity than automated testing did?" And phrased that way, you see it's not a dichotomy. It depends on what you would spend the time on instead of automated testing. It depends on whether you already had peer review in your process. It depends on what sort of automated tests you spend time on. It's very hard to say something general without those details. ---- Note that I'm not taking a stance against automated testing. I prefer working in a test-first style myself. I'm just saying it's not that simple.
hoten 5y ago
It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change. How do they know nothing broke? If there are no tests, they must spend an inordinate amount of time learning the entire system / product to gain any confidence they didn't break something, only to likely miss something that a senior team member will point out. The back/forth will take multiple developers time. At worst, it gets punted all the way to a QA team. Could be days. Or, with tests, that happens far less often and the feedback loop can be more like 10 minutes. Of course, tests don't solve onboarding, but they provide nice guard rails.
- dboreham 5y ago
  This assumes the tests are mostly valid. My experience in recent years has been that they won't be.
  - hoten 5y ago
    Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort because the original claim had no qualifiers, and was suggesting that any version of automated tests are orthogonal to developer productivity. All you must do to refute that is think of any codebase you were able to make progress on faster because a test told you what was wrong faster than it'd take you to blame source code and send an email to a developer you maybe have never met yet.
    - toast0 5y ago
      > Of course I'm assuming useful tests, why wouldn't I? Because useful tests seem pretty hard to have in practice. Especially when starting testing for a project without tests and a team without testing experience. Early testing reduces productivity, and the proposed gains may never develop.
jiggawatts 5y ago
I'm replying to this and also some of the sibling comments. No, automated development-time tests do not necessarily equate to higher quality, given that they: - Take time away from other activities - May provide a false positive, lulling developers into a false sense of confidence - Increase the time taken for certain CI/CD operations, sometimes by hours or days! - The presence of a large volume of "test" code means that certain refactoring operations take a lot longer, which is a real cost. People go into some work environments where tests DID help, and they generalise that to ALL work environments. Automated build-time tests are less important, and entire categories may be potentially unnecessary when: - The product is written in a strongly-typed language that catches most errors at compile time. - If high-level "linting" tools are used to further enhance the code quality before the executable ever runs. - If feedback from the production environment is more relevant. E.g.: for web applications with performance issues being monitored by an APM, but no critical code stability concerns at build time. Think typical web apps with no real consequences to a crash, not finance applications where a small error could mean Real Money. - Where time-to-market is more important than chasing 100% robustness at the expense of meeting release dates. You often see people from a PHP or Python background go on and on about the importance of tests, but those are dynamically typed languages with lots of unexpected pitfalls that only testing will uncover. Meanwhile entire teams do just fine without any automated tests when using languages like C#, Java, or Rust.
- cweagans 5y ago
  Types do a great job at assuring you’re getting generally the right kind of data in and out of different functions/methods, but they don’t assure that the program is actually doing the right thing. Strong typing just helps to assure that the program isn’t doing specific categories of the wrong thing (in the same way that Rust and Go make it difficult to write memory-unsafe code). I mean, Go and Rust both have testing capabilities built in. If it wasn’t necessary, why would they do that? Beyond the most trivial of projects, I can’t think of a single project that I’ve worked on (or even looked at on GitHub) that has weighed the costs and benefits of automated testing and decided it just wasn’t worth it.
  - jiggawatts 5y ago
itsdrewmiller 5y ago
Generally speaking "empirical evidence" means "published papers", with a little bit of flex for preprints or trustworthy-but-not-peer-reviewed experimental findings.
- gregjor 5y ago
  I was using it to mean actual data rather than anecdotes. The subject of programmer productivity is both much-studied and discussed and very hard to define, measure, and compare. The studies that do have some empirical evidence seem to show that team dynamics and individual programmer personalities have the most dramatic effects, compared to things like programming language, tests, style guides, etc. It's not that consistent styles and automated testing are bad ideas, it's that they don't clearly make a big dent in team productivity in cases where one or a few incompetent (or merely slow) programmers, or one jerk, can derail everyone's productivity. This I why I emphasized demonstrating a commitment to the team and showing some contributions before criticizing the environment and trying to propose changes. If you want the project to grind to a halt tell your new co-workers they are doing everything wrong. No automated test suite is going to fix that problem.
gregjor 5y ago
I think you are agreeing with me. There's anecdotal evidence like you offer. It's not necessarily obvious to everyone that automated tests improve code quality or it would be a settled issue (it's not). In my own career (40+ years) I have worked with automated testing and TDD, and without, and I can't say that TDD "obviously" improves code quality. I know other professional programmers who have that experience. Like everything else in software development it's probably situational and depends on the individuals and the team.

tayo42 5y ago

> No one is going to want to hear about how they could do things better from someone who just started I don't understand why more people don't get this. Like thanks for showing up and implying everyone is incompetent with your suggestions?

themitigating 5y ago
You shouldn't judge quality or suggestions by seniority
- givemeethekeys 5y ago
  It's not seniority that's the criteria. It's street cred / rapport.
- msh 5y ago
  It's not seniority, it's someone showing up who don't understand the challenges that lead to the current situation and not learning them before pointing at issues.
colechristensen 5y ago
It gets even worse when somebody is successful in being the new guy not understanding the new codebase and making big changes to recreate their previous workspace anyway. Fresh eyes and a fresh perspective are useful but don’t go recreating the universe right away.
gregjor 5y ago
Lack of humility kind of plagues our profession.

dehrmann 5y ago

> It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense. Classic Stockholm Syndrome.

beckingz 5y ago
Some call it stockholm syndrome, we call it the Spotify model!
- dehrmann 5y ago
  Probably should mention I'm an ex-Spotifier.
gregjor 5y ago
That's one way to look at it. When you put a bunch of smart people together on a team they all tend to think they're right and they can get very passionate, even when they don't have any data or measurements to back up their opinions. A little humility and time spent adapting to the environment, team, and code base can go a long way. Anecdotally my experience is that most programmers react to almost all code they didn't write as if it was crap. The more code they have to read and understand the more likely they are to complain about the quality of the code and the overall design of the system. Imagine someone looking at a photo of your house and telling you a hundred things wrong with it, without stepping foot inside or spending some time living there.

dehrmann 5y ago

One thing that can help build credibility before making larger suggestions is working on obvious, uncontroversial pain points in any spare time you have.

noufalibrahim 5y ago

This is an excellent observation. Thank you for making this. A pre requisite for "convincing" a large team is respect from the team. Assuming that it's not a toxic jungle, proven competence over a period of time is a good way of of earning said respect. Once you have that, you can cash it in for attention and people will listen. A more tactical thing is to actually do some work. You said that they don't have a style guide. Create one which you personally use and share it with your immediate team so that your own lives are better. Your immediate manager and team mates will have to work with you and if you start doing things which make your work obviously better, they'll pick up and that will give you mileage in the long run. Automated testing is hard in practice when there are a lot of external dependencies and when there's a huge legacy codebase. This is a case by case thing but just like before, if you have something to show and the respect to buy attention, you might be able to sell an idea to them.

gregjor 5y ago
"Show, don't tell" is a good principle. Don't tell the team how they should write better code. Show them an example that you can credibly argue represents improvement. Expect pushback and alternate opinions, don't fall in love with your particular style. Teams can get derailed over very minor things like tabs vs. spaces, so remember the important thing is a consistent style, not a particular style. Automated tests can be useful but don't expect the team to retrofit that, or for everyone to buy into it. You have to show the benefits in that environment.