6 ms·

This is really, really bad advice. Mutiny is hardly an answer to the problem here. It will certainly temporarily avoid the problems you face but if you are a me

by rwesty 6y ago

This is really, really bad advice. Mutiny is hardly an answer to the problem here. It will certainly temporarily avoid the problems you face but if you are a member of a team and this is truly how you act you will get chucked out very quickly. But since you bring up a few of the issues you are facing it's important to address them. I want to focus on unit tests to start. When I started my first programming job a couple of years ago I joined a team that demanded 100% code coverage. I hated them so much. I was still learning the ropes at this company and I only saw the unit tests as a barrier to getting my work done and earning my paycheck. My first solution was to create bogus tests that always passed. That was quickly discovered and I was reprimanded. My second solution was to get colleagues who shared my hate for unit tests to approve my PRs before they were reviewed by my team. That too was thwarted. Then one day I was working with a teammate on a new feature and we discovered a bug. He quickly opened up a test file and wrote a unit test, then he went tried a couple solutions until the test turned green. Then he looked at me and said, "When when you are working in a pile of crap, testing makes you feel more confident about your code." That was my first insight into the value of testing. Eventually I came around and stopped trying to avoid tests. I just did the damn work. Once I established trust with my teammates they began to let the pressure off my PRs and slowly the displeasure of writing tests went away. You pointed out a few different coding practices that frustrate you. And to be honest, those coding practices are not the gospel and should be deployed only when truly needed. However I think you have a serious problem with what a lot of us call being a good teammate. At the end of the day your goal should be to get the product shipped, once you focus on getting your features out the door, unit testing and pull requests become minor details in that process. At the end of the day those are just a cutesy to your teammates to show them that you are willing to be a responsible and helpful team member. Stop trying to fight everyone so much and maybe you will enjoy your job a little more.

tygrak 6y ago
The person you are replying to isn't suggesting to not do these things while working as a programmer professionally.
catalogia 6y ago
I don't think the GP's advice is meant for team projects. > "Don't make enterprise software. [...] Don't accept pull requests. Simply write software for yourself and have fun doing it."
- cblum 6y ago
  That's how I read it too. I've recently started doing that and it's been a breath of fresh air. I don't really like the stuff I work with, which is services. I think I've become good at it given the feedback I get from my peers every review cycle, but I really don't like it. I felt burned out for a long time because of that. Recently I've simply been doing what I'm interested in, in my spare time. That's learning about embedded systems, something I had an interest in in college but never pursued a career. And for fun, tinkering with old stuff that makes me nostalgic. I spent this last weekend coding in Pascal and messing around with FreeDOS :)
  - treis 6y ago
    It's hard to do just the fun stuff because that's not what makes good software. It's the unit tests and pull reviews and such that make the software reliable and covering all the niggling edge cases. And that ultimately is what makes a piece of software good.
    - tomc1985 6y ago
      Not so sure about that. Unit tests and pull reviews are stopgaps so that you don't have to hire 1000x engineers just to get some work done. The true masters of this craft may not need those things Believe it or not "all the edge cases" can still be perceived by the right mind. It's just that we as an industry have done seemingly everything we can to push those folks out, just look at OP as an example I've supported ten-digits-per-year (non-SAAS) businesses without unit tests or code reviews and oftentimes deploying straight to production. As the sole SWE for my codebase. Supporting hundreds of remote installations with nothing more than SSH tunnels relayed through an ancient, colocated linux box. And the software was very good, didn't ship with many bugs (and when it did they got fixed real quick), and there were never any catastrophic, non-recoverable issues, nor ever any questions on the integrity of the system or my reporting. We were never seriously hacked (to our knowledge). Crazy times... not sure I would do it again, but.... it can be done. My first dev job we did most of our work in vim sessions on the development server, and more than once I was asked to hotfix live code running in production. Through the grace of God and an abundance of caution nothing ever seriously blew up as a result of all this madness. (Though, ask my boss about the time he tried to move our MySQL instance onto some very early SSDs) Again, it can be done. I'm sure most of the old hats lying around have tons of stories like this.
cosmodisk 6y ago
While I dabbled with python and Delphi for a bit,my first real development was on Salesforce platform with their proprietary language called Apex. The first thing every developer learns on thos platform is that your code has to have at least 75% test coverage before it can be pushed to production.Testing was inevitable and ultimately part of anything I had to write. With time,I started reading more and more about development, tried different languages and etc.It was really fascinating to read how a lot of people hate testing or teams skip them if the deadlines need to be met. What testing taught me is that if the test is hard to write,it means that the code is crap.Every time I wrote some quick hack,it used to take me 10 times longer to write unit test.
- Aeolun 6y ago
  But what do you do if your initial codebase is crap. You literally cannot test until you refactor 50% of it into something semi-sensible.
  - popinman322 6y ago
    Then refactor 50% of it.
  - NortySpock 6y ago
    Short version: you find very small things that you can write tests around (pulling messy logic out into testable functions, writing tested utilities that replace dirty hacks, etc.) and start building your testing framework starting with that. Long version: Working Effectively with Legacy Code Book by Michael C. Feathers
  - brianwawok 6y ago
    It’s almost always bad as a new guy to come in and start refactoring. There are lots of weird if checks to deal with a vendor that returns bad data over the api every Sunday night. Your new clean code is going to crash and burn in all of these cases.
  - Hendrikto 6y ago
    That is not an argument against unit testing. That is an argument for applying it from the beginning…
battery_cowboy 6y ago
This is advice meant for personal projects, not work. Sorry if I didn't make that clear enough, but I thought it would be clear from context.
- andai 6y ago
  Dang, my question was going to be, if you have found the secret to monetizing that kind of thing :)
golemiprague 6y ago
I think it is excellent advice for someone who work by themselves and try to find some joy in coding after being in a rut. Yes, some conventions do emerge when being in a large team, it is inevitable, but this is not what this guy needs. Git + Trello is enough for personal projects or small teams. Anything else is a bonus or something you will add down the road and that includes testing or whatever other best practices. There are many jobs, especially in a non tech environments where you can be a sole dev or a part of a very small team, real small and mid businesses that generate value and are much more fun to work for for certain types of personality.
senderista 6y ago
Unit tests are time-consuming and tedious to write, and generally deliver poor effort-per-bug-found except for initial development (especially since they often displace cross-component tests which tend to catch more bugs). And the cases they test simply reflect the prejudices and lack of imagination of the author. A far better alternative IME is to use generative testing (e.g. property-based testing), which automates the tedium of generating test cases, and finds far more bugs to boot. Bonus: you'll understand your code much better after you're forced to identify and formalize invariants ("properties") in order to write your tests!

by rwesty 6y ago

tygrak 6y ago

The person you are replying to isn't suggesting to not do these things while working as a programmer professionally.

catalogia 6y ago

I don't think the GP's advice is meant for team projects. > "Don't make enterprise software. [...] Don't accept pull requests. Simply write software for yourself and have fun doing it."

cblum 6y ago
That's how I read it too. I've recently started doing that and it's been a breath of fresh air. I don't really like the stuff I work with, which is services. I think I've become good at it given the feedback I get from my peers every review cycle, but I really don't like it. I felt burned out for a long time because of that. Recently I've simply been doing what I'm interested in, in my spare time. That's learning about embedded systems, something I had an interest in in college but never pursued a career. And for fun, tinkering with old stuff that makes me nostalgic. I spent this last weekend coding in Pascal and messing around with FreeDOS :)
- treis 6y ago
  It's hard to do just the fun stuff because that's not what makes good software. It's the unit tests and pull reviews and such that make the software reliable and covering all the niggling edge cases. And that ultimately is what makes a piece of software good.
  - tomc1985 6y ago
    Not so sure about that. Unit tests and pull reviews are stopgaps so that you don't have to hire 1000x engineers just to get some work done. The true masters of this craft may not need those things Believe it or not "all the edge cases" can still be perceived by the right mind. It's just that we as an industry have done seemingly everything we can to push those folks out, just look at OP as an example I've supported ten-digits-per-year (non-SAAS) businesses without unit tests or code reviews and oftentimes deploying straight to production. As the sole SWE for my codebase. Supporting hundreds of remote installations with nothing more than SSH tunnels relayed through an ancient, colocated linux box. And the software was very good, didn't ship with many bugs (and when it did they got fixed real quick), and there were never any catastrophic, non-recoverable issues, nor ever any questions on the integrity of the system or my reporting. We were never seriously hacked (to our knowledge). Crazy times... not sure I would do it again, but.... it can be done. My first dev job we did most of our work in vim sessions on the development server, and more than once I was asked to hotfix live code running in production. Through the grace of God and an abundance of caution nothing ever seriously blew up as a result of all this madness. (Though, ask my boss about the time he tried to move our MySQL instance onto some very early SSDs) Again, it can be done. I'm sure most of the old hats lying around have tons of stories like this.

cosmodisk 6y ago

While I dabbled with python and Delphi for a bit,my first real development was on Salesforce platform with their proprietary language called Apex. The first thing every developer learns on thos platform is that your code has to have at least 75% test coverage before it can be pushed to production.Testing was inevitable and ultimately part of anything I had to write. With time,I started reading more and more about development, tried different languages and etc.It was really fascinating to read how a lot of people hate testing or teams skip them if the deadlines need to be met. What testing taught me is that if the test is hard to write,it means that the code is crap.Every time I wrote some quick hack,it used to take me 10 times longer to write unit test.

Aeolun 6y ago
But what do you do if your initial codebase is crap. You literally cannot test until you refactor 50% of it into something semi-sensible.
- popinman322 6y ago
  Then refactor 50% of it.
- NortySpock 6y ago
  Short version: you find very small things that you can write tests around (pulling messy logic out into testable functions, writing tested utilities that replace dirty hacks, etc.) and start building your testing framework starting with that. Long version: Working Effectively with Legacy Code Book by Michael C. Feathers
- brianwawok 6y ago
  It’s almost always bad as a new guy to come in and start refactoring. There are lots of weird if checks to deal with a vendor that returns bad data over the api every Sunday night. Your new clean code is going to crash and burn in all of these cases.
- Hendrikto 6y ago
  That is not an argument against unit testing. That is an argument for applying it from the beginning…

battery_cowboy 6y ago

This is advice meant for personal projects, not work. Sorry if I didn't make that clear enough, but I thought it would be clear from context.

andai 6y ago
Dang, my question was going to be, if you have found the secret to monetizing that kind of thing :)

golemiprague 6y ago

I think it is excellent advice for someone who work by themselves and try to find some joy in coding after being in a rut. Yes, some conventions do emerge when being in a large team, it is inevitable, but this is not what this guy needs. Git + Trello is enough for personal projects or small teams. Anything else is a bonus or something you will add down the road and that includes testing or whatever other best practices. There are many jobs, especially in a non tech environments where you can be a sole dev or a part of a very small team, real small and mid businesses that generate value and are much more fun to work for for certain types of personality.

senderista 6y ago

Unit tests are time-consuming and tedious to write, and generally deliver poor effort-per-bug-found except for initial development (especially since they often displace cross-component tests which tend to catch more bugs). And the cases they test simply reflect the prejudices and lack of imagination of the author. A far better alternative IME is to use generative testing (e.g. property-based testing), which automates the tedium of generating test cases, and finds far more bugs to boot. Bonus: you'll understand your code much better after you're forced to identify and formalize invariants ("properties") in order to write your tests!