11 ms·

I have a feeling I know why he hired you instead of writing it himself... Also contributing my part: a boss declining unit tests because they cost money. In th

by _def 7y ago

I have a feeling I know why he hired you instead of writing it himself... Also contributing my part: a boss declining unit tests because they cost money. In the meantime, he's wondering how crucial bugs appear again and again and urges us to be more careful. It's always a relieve to leave those places :)

cryptica 7y ago
This mindset of "you don't need tests, just don't write bugs" sounds extremely naive and amateurish at first but having worked at many different kinds of large and small tech companies around the world for over a decade, I now think that there is actually real wisdom behind that mindset and I've met some very talented engineers who share that thinking to various extents. Debugging trains you to think about code. I think most of my programming skill comes from my open source project work where I didn't write tests initially. Now I can simulate code in my mind without having a computer in front of me. This is a really useful skill - You need to be under some kind of mental stress to learn this kind of skill. When you don't have tests to rely on, your mind is forced to hold on to more details about different interralated parts of the code and over time, this mental stress trains you to hold a massive amount of detail in your mind and this helps you to write much better code. Also, being forced to hold a lot of code in your mind gives you a strong incentive to design clean simple architectures. Writing bug-free code is not difficult for me now. Even on very complex distributed projects. I do write tests for my open source projects now but I do it at the end after everything is working. The purpose of tests for me now is just to lock down the code to prevent regressions. For some complex projects, I do TDD but I focus more on high level integration tests.
- _def 7y ago
  If you are out of the loop because you didn't work on a project for half a year or even are completely new to a project, this approach seems pretty impossible for myself. At least with the dynamics I had at the job described above (which included lots of project rotation among devs). I'm sure there are fitting settings where this approach might work, though.

by _def 7y ago

cryptica 7y ago

This mindset of "you don't need tests, just don't write bugs" sounds extremely naive and amateurish at first but having worked at many different kinds of large and small tech companies around the world for over a decade, I now think that there is actually real wisdom behind that mindset and I've met some very talented engineers who share that thinking to various extents. Debugging trains you to think about code. I think most of my programming skill comes from my open source project work where I didn't write tests initially. Now I can simulate code in my mind without having a computer in front of me. This is a really useful skill - You need to be under some kind of mental stress to learn this kind of skill. When you don't have tests to rely on, your mind is forced to hold on to more details about different interralated parts of the code and over time, this mental stress trains you to hold a massive amount of detail in your mind and this helps you to write much better code. Also, being forced to hold a lot of code in your mind gives you a strong incentive to design clean simple architectures. Writing bug-free code is not difficult for me now. Even on very complex distributed projects. I do write tests for my open source projects now but I do it at the end after everything is working. The purpose of tests for me now is just to lock down the code to prevent regressions. For some complex projects, I do TDD but I focus more on high level integration tests.

_def 7y ago
If you are out of the loop because you didn't work on a project for half a year or even are completely new to a project, this approach seems pretty impossible for myself. At least with the dynamics I had at the job described above (which included lots of project rotation among devs). I'm sure there are fitting settings where this approach might work, though.