5 ms·

The main problem with this is that author is creating a false dichotomy between writing great software and running a business(hustling). I don't think you have

The main problem with this is that author is creating a false dichotomy between writing great software and running a business(hustling). I don't think you have to forgo one to succeed at the other. I just think that you need to make a decision up front what your businesses core competency is, if it is supposed to be writing great software, then really should you be doing things like "Stop being such a nerd".?

freshfey 15y ago
Max Levchin phrased this very point beautifully on his Startup School talk (I think it was an advice by Peter Thiel): "A difficult problem doesn't necessarily mean a valuable problem". Your job as a programmer is to add value. Now if you keep working on super interesting stuff, that doesn't add value, what's the point really? You should spend your free time on the interesting problems that don't add value.
- j_baker 15y ago
  Either that or find interesting problems that are valuable.
choxi 15y ago
by "writing great software" do you mean writing software that other programmers will admire? or writing software that your users will love? you shouldn't let the first one get in the way of the second.
- mgrouchy 15y ago
  I mean, writing software that is usable, useful, maintainable, robust and reliable. This is the type of code that both other developers AND your users will love.
- viscanti 15y ago
  It really depends what problem you're solving. Not all problems require elegant solutions that other programmers will admire. If that's the case, you have several options: 1. Switch to a "harder" problem (however that's defined), that necessitates an elegant solution that will impress other programmers. 2. Ignore the desire to impress people who don't matter to your business. 3. There is no third option.
- j_baker 15y ago
  I agree in principle, but not in practice. Yeah, in an ideal world, everyone would set aside their own personal desires and wants to focus on the business's goals. And yes, you have to choose the customers' goals if the two should ever conflict. But in practice, human beings are needy animals who aren't always practical. I find that programmers (including myself) can be more productive if you indulge that side a little bit. In short, I think that you can have your cake and eat it too: code that programmers appreciate working on and also serves the customers' needs.

freshfey 15y ago

Max Levchin phrased this very point beautifully on his Startup School talk (I think it was an advice by Peter Thiel): "A difficult problem doesn't necessarily mean a valuable problem". Your job as a programmer is to add value. Now if you keep working on super interesting stuff, that doesn't add value, what's the point really? You should spend your free time on the interesting problems that don't add value.

j_baker 15y ago
Either that or find interesting problems that are valuable.

choxi 15y ago

by "writing great software" do you mean writing software that other programmers will admire? or writing software that your users will love? you shouldn't let the first one get in the way of the second.

mgrouchy 15y ago
I mean, writing software that is usable, useful, maintainable, robust and reliable. This is the type of code that both other developers AND your users will love.
viscanti 15y ago
It really depends what problem you're solving. Not all problems require elegant solutions that other programmers will admire. If that's the case, you have several options: 1. Switch to a "harder" problem (however that's defined), that necessitates an elegant solution that will impress other programmers. 2. Ignore the desire to impress people who don't matter to your business. 3. There is no third option.
j_baker 15y ago
I agree in principle, but not in practice. Yeah, in an ideal world, everyone would set aside their own personal desires and wants to focus on the business's goals. And yes, you have to choose the customers' goals if the two should ever conflict. But in practice, human beings are needy animals who aren't always practical. I find that programmers (including myself) can be more productive if you indulge that side a little bit. In short, I think that you can have your cake and eat it too: code that programmers appreciate working on and also serves the customers' needs.