Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm a good engineer but I suck at building stuff

lionelbarrow.com

Post reply on HN
Print view View original

11–20 of 128 posts

Re: I'm a good engineer but I suck at building stuff

#11

Post by ianstormtaylor »

reefoctopus wrote: post #8
ogreveins wrote: post #6

Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.

4. Make it manageable.

I'd probably swap them:

1. Make it work.

2. Make it not break.

3. Make it manageable.

4. Make it fast.

Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.

Re: I'm a good engineer but I suck at building stuff

#12

Post by cloverich »

daenz wrote: post #3

> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the be…

> because you lack experience.

Well said. IMHO, this is the core of the issue and the thing that has helped me both move on and improve. You have to be ok writing crappy code because, in lieue of experience or someone to (on the spot) help you, its the only way forward. As long as you're professional about learning and refactoring, the best you can do is keep moving, keep learning, keep refactoring. Then eventually, help move others through that gauntlet more quickly.

Re: I'm a good engineer but I suck at building stuff

#13

Post by stevetrewick »

cloverich wrote: post #12
daenz wrote: post #3

> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the be…

> because you lack experience. Well said. IMHO, this is the core of the issue and the thing that has helped me both move on and improve. You have to be ok writing crappy code because, in lieue of experience or someone to (on the spot) help you, its the only way forward. As long as you're professional about learning and refactoring, the best you can do is keep moving, keep learning, keep refactoring. Then eventually,…

Absolutely. First make it work, then make it better.

Re: I'm a good engineer but I suck at building stuff

#14

Post by koolba »

ogreveins wrote: post #6

Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.

4. Throw it away and rebuild it now that you know how it really should work.

Re: I'm a good engineer but I suck at building stuff

#15

Post by ogreveins »

ianstormtaylor wrote: post #11
reefoctopus wrote: post #8

Earlier quoted context omitted.

4. Make it manageable.

I'd probably swap them: 1. Make it work. 2. Make it not break. 3. Make it manageable. 4. Make it fast. Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.

I'd agree with this. My last couple of projects did have a couple of hacks that bordered on spaghetti code until they were sufficiently cleaned up.

Re: I'm a good engineer but I suck at building stuff

#16

Post by stevetrewick »

ianstormtaylor wrote: post #11
reefoctopus wrote: post #8

Earlier quoted context omitted.

4. Make it manageable.

I'd probably swap them: 1. Make it work. 2. Make it not break. 3. Make it manageable. 4. Make it fast. Otherwise I find that trying to make something fast before making it manageable usually ends up in crazy hacks that are hard to undo later.

3.5 Profile it to see whether or not it needs to be faster

Re: I'm a good engineer but I suck at building stuff

#18

Post by noonespecial »

daenz wrote: post #3

> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the be…

I have a simple mantra that helps me remember this.

"Its clay, not stone".

Re: I'm a good engineer but I suck at building stuff

#19

Post by robohamburger »

jrumbut wrote: post #2

I feel like my experience is the opposite of this. I've never understood something until it stood between me and building what I needed to build. This approach has been great professionally, but lately I'm becoming more interested in theory intensive fields and struggling to find resources that teach from the perspective of someone who wants to build something that requires the knowledge involved, rather than someone…

I agree! I have a hard time focusing on something that is purely academic unless said academic thing seems to have a property I want to explore on my own or use to build something.

I got several C's in calculus because I was too busy messing with slightly different calculus instead of doing the problem sets for the tests.

I regret nothing, but I wish I could learn the same way most people seem to be able to sometimes.

Re: I'm a good engineer but I suck at building stuff

#20

Post by 6stringmerc »

koolba wrote: post #14
ogreveins wrote: post #6

Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.

4. Throw it away and rebuild it now that you know how it really should work.

In some cases this is excellent advice regarding a story or essay re-write as well.
Post reply on HN