6 ms·

Not much useful stories based on my real life story. My friends are programmers, too. But they never get to senior level programmers, even if they keep working

Not much useful stories based on my real life story. My friends are programmers, too. But they never get to senior level programmers, even if they keep working in software engineering for more than 10 years, or 20 years. The reason? They refused to learn unit testing. They love manual testing, from function to the software. God bless them.

gherkinnn 4y ago
Is it the lack of unit testing or a lack of learning new tools and techniques once knowing just enough to get a job?
- revskill 4y ago
  Of all basic senior skills, unit testing is the first one need to know.
  - nuclearnice1 4y ago
    What’s second and third?
    - revskill 4y ago
      I'm not sure about them, but i'm sure the fourth is know how to remove your code.
      - suction 4y ago
    - gherkinnn 4y ago
      Zeroth is knowing when not to reach for a tool you do know.
  - rightbyte 4y ago
    Unit testing is quite overrated. Testing stuff "by hand" is more or less writing a unit test you delete afterwards.
    - lazide 4y ago
      Sounds like it would be hard to scale yourself, time wise, If you kept deleting the automation.
      - astrange 4y ago
        Unit tests can have the opposite problem; if they never fail they’re not contributing and you still have to maintain them. They are not the most productive way to get end to end automated test coverage.
        KerrAvon 4y ago
        They’re still documenting how the code is supposed to behave. If they really never fail no matter how you change the code, you may not be testing the right things.
        astrange 4y ago
        The issue is that too often they fail not because the code was incorrect, but because it changed and the test/mocks are incorrect. Higher level tests stay valid because they’re things like “none of the command line args should crash”. Besides that, sometimes code just doesn’t change (say a basic math library). Then you’re mostly testing your compiler, which is useful but an intentional approach would be better.
        gherkinnn 4y ago
        I agree with your first point. But there’s somebody out there telling us that a true unit test has no mocks. Or something. Unit tests do come in handy when building a maths library.l or similar. Not in terms of catching a regression, but to help build it in the first place. One of the few places where TDD might actually be helpful.
  - xupybd 4y ago
    In the pragmatic programmer the author talks about unit testing as a great way to learn how to write testable code. They mention the benefits of that sort of code and how they don't always write unit tests as that's not the most important part.
  - jongjong 4y ago
    I prefer integration testing over unit testing because each test case covers many more lines of code (since it also traverses dependencies). You can use mocks and stubs to allow the test suite to reset/set the state of the system between each test case so integration tests don't have to be brittle, unreliable or require launching other services on the side. I find that it's a good architectural pattern if the main state stores in a software can be easily substituted with mocks or stubs; in my experience, this makes the software more reliable, easier to maintain and more testable.
    - rikroots 4y ago
      This. I have nothing against unit testing; there's been times when a unit test (often written by someone else) has stopped me pushing some truly stupid code to production. But when I started developing my canvas library (for fun, not work) I decided early on that unit testing every line of code was not only sucking the joy from the work, but also too hard to cover all the edge cases of what I was trying to deliver: responsive, interactive, animated graphics, often controlled by user interaction with the canvas element. So instead I developed a big bunch of demos which try to cover the full functionality of the library, which I can visually check locally before pushing code changes to the repo[1]. The big drawback is I have to check all these tests/demos manually (across browsers and devices) before releasing a new version of the library into the wild. Automating that process is on my list of Things To Do - if anyone has suggestions/insights into current tooling/testing suites that could help me then I'm very willing to listen and learn! [1] - https://scrawl-v8.rikweb.org.uk/demonstrations https://scrawl-v8.rikweb.org.uk/demonstrations
      - jongjong 4y ago
        I still use unit testing for modules which are particularly complex.
holoduke 4y ago
What is a senior developer anyways? I am a around developer, but even after 20 years I see people around me much better than I am. Still I managed to setup multiple companies quite succesfully. But am I a typical senior developer? No I am not. I am quite mediocre.
- revskill 4y ago
  A senior developer is one who can read, write and TEST their own code in an automatic way.
  - matwood 4y ago
    So I was a senior dev day 1 some 20+ years ago :D
  - forrestthewoods 4y ago
    I do not think you will find many people who agree with this definition. Reading, writing, and testing your own code is entry level. That’s most basic of basics. My favorite definition of senior was “someone who can jump into any system in the project, including parts they aren’t familiar with, to diagnose and fix any issue”. That’s a little unfair for extremely large projects, but it’s pretty close. Alternatively, senior developers are given vague problems and it’s up them to design, implement, and own solutions. Staff/principle, and to less extent senior, devs are also responsibly for wisely identifying what problems even need to be solved.
    - mod 4y ago
      I believe I meet your two definitions, but probably not that of the guy you responded to. I mean I CAN write tests, and I have on a some particular projects, but it was the exception, not the rule. I'm not trying to ruffle any feathers--I'm not anti-testing or anything. I just never worked somewhere it was part of the culture. Just small shops getting stuff done. Anyway I don't feel particularly knowledgeable about testing. I encountered a lot of situations (in web dev) where I didn't know how to mock responses and stuff like that, and couldn't get coverage in some spots. But I debugged complex bugs in foreign systems a lot. I was the go-to guy at one shop for that. Full stack dev, and solo for most of them, so I got to design and implement my own solutions. Discover my own complexity, debug my own bugs. I think I've probably built, and at least temporarily maintained, at least 15-20 rails apps, and there's countless non-rails apps. Many of them are still up ~5-10 years later, just how I built them. 23 years coding, per the author of this piece, but only 5 years of getting paid for it. A generalist in the web world, but little experience outside of web. Anyway, all that to say, I have no idea if I'm senior or not. I've never been called it. The metrics are not clear (or consistent) and I feel like maybe it's impostor syndrome to NOT call myself senior, but maybe I'm actually not. I don't know! This also may be partially due to being self-taught. I have gaps in my knowledge that just reflect my own experience, rather than that of a curriculum. I'll report back if I ever get more professional experience.
PuppyKhan 4y ago
I wrote the perfect article for your friends: "The Case Against Unit Tests" https://medium.com/avenue-8/the-case-against-unit-tests-b4239b5c4074 https://medium.com/avenue-8/the-case-against-unit-tests-b423... They have their use, but they have many shortcomings.
- Aeolun 4y ago
  Many shortcomings, none of which mean you can ignore them in favour of manual testing.
tracerbulletx 4y ago
Most places I've worked testing is just table stakes and built into the processes of all the teams. Getting to the higher "seniority" levels is generally just about putting together a history of impactful accomplishments to cite, and using that experience to have a wider impact on the business besides the code you write. Like when you are in a meeting you are the one suggesting better ways to solve a problem, or you get a bunch of engineering teams to go in the same direction together to solve a problem no one team could solve alone, or you solve an important problem no one asked you to solve because only you could see it was a problem. Stuff like that. Also people like working with you and you socialize your self and are aware of what's going on in the business.
ChrisMarshallNY 4y ago
I suspect that there may be a bit more to it, than that. You may want to find different friends to enhance your sample group. I did write something about test harnesses vs. unit tests, a couple of years ago: https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u... TL;DR, test like crazy, but test smart. My testing code (often, not unit tests), is generally much bigger than the code under test, but I'm just an old fogey, and everyone knows that old dudes can't code. I’m pretty sure that my code is so bad, it needs all that testing. I've learned that lots of folks have some "litmus test," that they like to apply to others, where, if not passed, they are "bad programmers." In my case, I've learned that I'm a really "bad programmer," because I fail everyone's litmus test. In fact, I make a point of it. Hey, it's a big world, and there's lots of freedom to believe as we please.

gherkinnn 4y ago

Is it the lack of unit testing or a lack of learning new tools and techniques once knowing just enough to get a job?

revskill 4y ago
Of all basic senior skills, unit testing is the first one need to know.
- nuclearnice1 4y ago
  What’s second and third?
  - revskill 4y ago
    I'm not sure about them, but i'm sure the fourth is know how to remove your code.
    - suction 4y ago
  - gherkinnn 4y ago
    Zeroth is knowing when not to reach for a tool you do know.
- rightbyte 4y ago
  Unit testing is quite overrated. Testing stuff "by hand" is more or less writing a unit test you delete afterwards.
  - lazide 4y ago
    Sounds like it would be hard to scale yourself, time wise, If you kept deleting the automation.
    - astrange 4y ago
      Unit tests can have the opposite problem; if they never fail they’re not contributing and you still have to maintain them. They are not the most productive way to get end to end automated test coverage.
      - KerrAvon 4y ago
        They’re still documenting how the code is supposed to behave. If they really never fail no matter how you change the code, you may not be testing the right things.
        astrange 4y ago
        The issue is that too often they fail not because the code was incorrect, but because it changed and the test/mocks are incorrect. Higher level tests stay valid because they’re things like “none of the command line args should crash”. Besides that, sometimes code just doesn’t change (say a basic math library). Then you’re mostly testing your compiler, which is useful but an intentional approach would be better.
        gherkinnn 4y ago
        I agree with your first point. But there’s somebody out there telling us that a true unit test has no mocks. Or something. Unit tests do come in handy when building a maths library.l or similar. Not in terms of catching a regression, but to help build it in the first place. One of the few places where TDD might actually be helpful.
- xupybd 4y ago
  In the pragmatic programmer the author talks about unit testing as a great way to learn how to write testable code. They mention the benefits of that sort of code and how they don't always write unit tests as that's not the most important part.
- jongjong 4y ago
  I prefer integration testing over unit testing because each test case covers many more lines of code (since it also traverses dependencies). You can use mocks and stubs to allow the test suite to reset/set the state of the system between each test case so integration tests don't have to be brittle, unreliable or require launching other services on the side. I find that it's a good architectural pattern if the main state stores in a software can be easily substituted with mocks or stubs; in my experience, this makes the software more reliable, easier to maintain and more testable.
  - rikroots 4y ago
    This. I have nothing against unit testing; there's been times when a unit test (often written by someone else) has stopped me pushing some truly stupid code to production. But when I started developing my canvas library (for fun, not work) I decided early on that unit testing every line of code was not only sucking the joy from the work, but also too hard to cover all the edge cases of what I was trying to deliver: responsive, interactive, animated graphics, often controlled by user interaction with the canvas element. So instead I developed a big bunch of demos which try to cover the full functionality of the library, which I can visually check locally before pushing code changes to the repo[1]. The big drawback is I have to check all these tests/demos manually (across browsers and devices) before releasing a new version of the library into the wild. Automating that process is on my list of Things To Do - if anyone has suggestions/insights into current tooling/testing suites that could help me then I'm very willing to listen and learn! [1] - https://scrawl-v8.rikweb.org.uk/demonstrations https://scrawl-v8.rikweb.org.uk/demonstrations
    - jongjong 4y ago
      I still use unit testing for modules which are particularly complex.

holoduke 4y ago

What is a senior developer anyways? I am a around developer, but even after 20 years I see people around me much better than I am. Still I managed to setup multiple companies quite succesfully. But am I a typical senior developer? No I am not. I am quite mediocre.

revskill 4y ago
A senior developer is one who can read, write and TEST their own code in an automatic way.
- matwood 4y ago
  So I was a senior dev day 1 some 20+ years ago :D
- forrestthewoods 4y ago
  I do not think you will find many people who agree with this definition. Reading, writing, and testing your own code is entry level. That’s most basic of basics. My favorite definition of senior was “someone who can jump into any system in the project, including parts they aren’t familiar with, to diagnose and fix any issue”. That’s a little unfair for extremely large projects, but it’s pretty close. Alternatively, senior developers are given vague problems and it’s up them to design, implement, and own solutions. Staff/principle, and to less extent senior, devs are also responsibly for wisely identifying what problems even need to be solved.
  - mod 4y ago
    I believe I meet your two definitions, but probably not that of the guy you responded to. I mean I CAN write tests, and I have on a some particular projects, but it was the exception, not the rule. I'm not trying to ruffle any feathers--I'm not anti-testing or anything. I just never worked somewhere it was part of the culture. Just small shops getting stuff done. Anyway I don't feel particularly knowledgeable about testing. I encountered a lot of situations (in web dev) where I didn't know how to mock responses and stuff like that, and couldn't get coverage in some spots. But I debugged complex bugs in foreign systems a lot. I was the go-to guy at one shop for that. Full stack dev, and solo for most of them, so I got to design and implement my own solutions. Discover my own complexity, debug my own bugs. I think I've probably built, and at least temporarily maintained, at least 15-20 rails apps, and there's countless non-rails apps. Many of them are still up ~5-10 years later, just how I built them. 23 years coding, per the author of this piece, but only 5 years of getting paid for it. A generalist in the web world, but little experience outside of web. Anyway, all that to say, I have no idea if I'm senior or not. I've never been called it. The metrics are not clear (or consistent) and I feel like maybe it's impostor syndrome to NOT call myself senior, but maybe I'm actually not. I don't know! This also may be partially due to being self-taught. I have gaps in my knowledge that just reflect my own experience, rather than that of a curriculum. I'll report back if I ever get more professional experience.

PuppyKhan 4y ago

I wrote the perfect article for your friends: "The Case Against Unit Tests" https://medium.com/avenue-8/the-case-against-unit-tests-b4239b5c4074 https://medium.com/avenue-8/the-case-against-unit-tests-b423... They have their use, but they have many shortcomings.

Aeolun 4y ago
Many shortcomings, none of which mean you can ignore them in favour of manual testing.

tracerbulletx 4y ago

Most places I've worked testing is just table stakes and built into the processes of all the teams. Getting to the higher "seniority" levels is generally just about putting together a history of impactful accomplishments to cite, and using that experience to have a wider impact on the business besides the code you write. Like when you are in a meeting you are the one suggesting better ways to solve a problem, or you get a bunch of engineering teams to go in the same direction together to solve a problem no one team could solve alone, or you solve an important problem no one asked you to solve because only you could see it was a problem. Stuff like that. Also people like working with you and you socialize your self and are aware of what's going on in the business.

ChrisMarshallNY 4y ago

I suspect that there may be a bit more to it, than that. You may want to find different friends to enhance your sample group. I did write something about test harnesses vs. unit tests, a couple of years ago: https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u... TL;DR, test like crazy, but test smart. My testing code (often, not unit tests), is generally much bigger than the code under test, but I'm just an old fogey, and everyone knows that old dudes can't code. I’m pretty sure that my code is so bad, it needs all that testing. I've learned that lots of folks have some "litmus test," that they like to apply to others, where, if not passed, they are "bad programmers." In my case, I've learned that I'm a really "bad programmer," because I fail everyone's litmus test. In fact, I make a point of it. Hey, it's a big world, and there's lots of freedom to believe as we please.