4 ms·

It's not always a trick; sometimes it's quite sincere. My first boss as a programmer hired me because he tried to write the app himself and discovered that ther

It's not always a trick; sometimes it's quite sincere. My first boss as a programmer hired me because he tried to write the app himself and discovered that there were more efficient uses of his talents. However he did learn some important lessons that he passed on to me: 1. instead of giving full word names to variables, it is more efficient to just name the first one `a`, and the second one `b`, and then on the second pass through the alphabet `a1`, third pass `a2`, etc. He couldn't understand why I didn't re-use his old code written with this scheme or why I didn't adopt it going forward. 2. It is far more efficient to simply not write the bugs, as opposed to wasting so much time debugging them. Thanks for the education Frank, I did learn a lot from you.

_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.
codeisawesome 7y ago
Are you sure you didn’t work for “Yogi” Berra? That second quote is beautiful :’D
karmakaze 7y ago
It's strange to see these two points mentioned. One of the great programmers I worked with always used mostly two character variable names and rarely produced bugs. His title was Chief Scientist.
- jrs235 7y ago
  Ah yes. There is a strong correlation between the amount of code you write and the number of bugs you produce. Typing fewer characters means writing "less" code code thus fewer bugs. But a larger factor is that the shorter and more cryptic you write variables names, the less you will be asked to keep writing code, thus you will produce fewer bugs. To produce the fewest number of bugs, write less code.
  - karmakaze 7y ago
    Not quite. He single-handedly re-wrote the company's core framework from one platform to support multi-platform.

_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.

codeisawesome 7y ago

Are you sure you didn’t work for “Yogi” Berra? That second quote is beautiful :’D

karmakaze 7y ago

It's strange to see these two points mentioned. One of the great programmers I worked with always used mostly two character variable names and rarely produced bugs. His title was Chief Scientist.

jrs235 7y ago
Ah yes. There is a strong correlation between the amount of code you write and the number of bugs you produce. Typing fewer characters means writing "less" code code thus fewer bugs. But a larger factor is that the shorter and more cryptic you write variables names, the less you will be asked to keep writing code, thus you will produce fewer bugs. To produce the fewest number of bugs, write less code.
- karmakaze 7y ago
  Not quite. He single-handedly re-wrote the company's core framework from one platform to support multi-platform.