2 ms·

I don’t know how many k hours of coding I have. 10k is long in the rear-view mirror. My advice? Ship fast. The way you get good is by being fast. Think of two

I don’t know how many k hours of coding I have. 10k is long in the rear-view mirror. My advice? Ship fast. The way you get good is by being fast. Think of two junior engineers, we’ll call them Uno and Dos. Uno is working hard on a feature and wants to get it working, and working right. Uno spends two full weeks working on it and then sends out a PR. Dos starts by thinking “fast”, and figures out how to send a PR within only two days. This PR is, of course, horribly incomplete. Uno’s PR is bogged down in review because there are major problems. Dos, on the other hand, gets some really quick feedback from the team lead saying “you can extract this function and write a test for it, please do that.” The same applies not only to junior engineers working on a small scale within a team, but to large scale projects being shipped by the whole team. Ship it fast, get feedback fast, and let it blow up in your face if you think you can survive the consequences. The same applies to me. The best stuff I have ever shipped has been shipped fast and fixed afterwards. If you want to raise the quality of your code, the way you do it is by meeting the requirements fast. If you beat the clock when it comes to baseline requirements, you get extra time to refactor and redesign components. There are also a million things you can only learn by shipping code. Learn those things sooner; ship fast.

npalli 2y ago
This whole thesis rests on the team not knowing what to build and shipping fast to get more learning cycles. Works if you don't know anything (said juniors) or new fields (like internet or social or mobile etc.). Lot of places (including formerly new fields) that is not true anymore. Not everything is move fast and break things - which was Facebook's motto until 2014.
- klodolph 2y ago
  I say this is wrong, and the true reason to ship slower is when shipping something wrong is catastrophic. Let’s say you are making something well-understood like a PCB. To me, the “ship fast” option is to make a prototype PCB fast, even if it doesn’t meet the design constraints (say, size, power consumption, cost), That’s because very few things we build are so well-understood that you can design and then ship. Development is, in its most ideal form, highly iterative and incorporates data from the field as soon as feasible. In the PCB design scenario, we want the prototype sooner because we can learn things like “this design is too sensitive to EMI”, which may necessitate a redesign or at the very minimum re-spinning the PCBs. PCBs are very similar to ICs. ICs get fewer prototypes and a more careful shipping process because it can cost millions to do a new stepping. Not because IC design is poorly understood or mysterious, but because mistakes are costly. That is the real reason you would slow down. Maybe you spend more time and money doing simulations for your ICs, maybe you have them go through more design reviews. Likewise, shipping a bad medical device or bad space probe is usually catastrophic.

npalli 2y ago

This whole thesis rests on the team not knowing what to build and shipping fast to get more learning cycles. Works if you don't know anything (said juniors) or new fields (like internet or social or mobile etc.). Lot of places (including formerly new fields) that is not true anymore. Not everything is move fast and break things - which was Facebook's motto until 2014.

klodolph 2y ago
I say this is wrong, and the true reason to ship slower is when shipping something wrong is catastrophic. Let’s say you are making something well-understood like a PCB. To me, the “ship fast” option is to make a prototype PCB fast, even if it doesn’t meet the design constraints (say, size, power consumption, cost), That’s because very few things we build are so well-understood that you can design and then ship. Development is, in its most ideal form, highly iterative and incorporates data from the field as soon as feasible. In the PCB design scenario, we want the prototype sooner because we can learn things like “this design is too sensitive to EMI”, which may necessitate a redesign or at the very minimum re-spinning the PCBs. PCBs are very similar to ICs. ICs get fewer prototypes and a more careful shipping process because it can cost millions to do a new stepping. Not because IC design is poorly understood or mysterious, but because mistakes are costly. That is the real reason you would slow down. Maybe you spend more time and money doing simulations for your ICs, maybe you have them go through more design reviews. Likewise, shipping a bad medical device or bad space probe is usually catastrophic.