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

121–128 of 128 posts

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

#121

Post by BugsBunnySan »

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…

The thing that helped me out of this, was seeing writing code like forging a sword, where you repeatedly heat up the metal, hammer it into shape and then cool it down again. (note: IANASwordSmith)

This works because heating up the metal makes it easier for it to arrange itself into a more optimal configuration and then you hammer it into shape and cool it down again to preserve the awesomeness you already reached. Then you repeat that process a thousand times until you have a katana that can cut through steel.

So, don't worry about just implementing a feature very roughly and breaking apart old structures you already put into place, you're just "heating up the metal". To see how everything should work and what it should behave like (i.e. "hammering it into shape"). As long as you then do the clean up/refactoring and put everything in the right place and such, i.e. "cooling it down again", you'll end up with awesome code that's robust and expresses what should be done very well.

So, in a way, imagine you're a smith at the forge, forging your code like a Hatori Hanzo sword, which is also a nice methapor, I think (with the difference, that your code's purpose is hopefully not cutting peoples heads of!).:)

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

#122

Post by scottious »

swanson wrote: post #29
scottious wrote: post #17

God I wish the rest of my team would read this... I feel like they're more concerned with what stupid monad to use or how to create a really deeply nested class hierarchy than making features and bug fixes that deliver value to people who use the software

Why not link it to them and then discuss it over a team lunch?

That makes too much sense! Honestly though, the fact that that seemingly obvious suggestion is actually quite difficult means there's something wrong with me or our team culture... something to think about I guess.

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

#123

Post by BuckRogers »

zer00eyz wrote: post #88
humanrebar wrote: post #65

Earlier quoted context omitted.

> ...and if it is that bad they are going to give you grief for it and you can fix it. You can't always fix it. If it were that simple, everyone would be using Python 3 already.

I think the argument could be made that python 3 is an example of "great engineering" and (in hindsight) "poor customer understanding". Python 3 is the polar opposite to Linus' meltdown on not breaking user space see: https://lkml.org/lkml/2012/12/23/75 Sadly I like Python 3 and wish it was more popular.

I see Python3 as poor engineering. There are no technical reasons why you can't run bytecode from both 2 and 3 together. Various JVMs and the CLR solved this problem. They created their own problem by refusing to built or maintain a comprehensive solution. As well, there's nothing in Python3 that didn't already exist in the Python2 ecosystem or was trivial to add to Python2 (backport or otherwise). Thus many of us see CPython3 as technical churn rather than technical innovation.

I share your sentiment about having 1 version of Python but it's not the users fault. It's the core dev team's and Guido's.

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

#124

Post by epalmer »

grrowl wrote: post #115
epalmer wrote: post #58

Earlier quoted context omitted.

I frequently use TODOs and I don't get crazy if I don't go back and do all the TODOs. Some seem important at the time and become less so with age. Others become more important.

I feel like this leads down a dangerous path of no signal-to-noise ratio and destroys your hope of finding relevant TODOs. Better to, as part of revisiting them, rewrite the comment to explain the de facto behaviour for yourself (and others) in future. If you're not going to do them, anyhow.

You make good points. I don't use them so much as to bother me. I code for a team size of one (me) so that gives me liberties that I might not take elsewhere.

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

#125

Post by jrumbut »

JimboOmega wrote: post #27
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'm always worried that it's not great for me professionally. Because the "cool kids" are always off learning the hot new thing, and I can do what I need to in the "old" thing, and so I don't learn the hot new thing. Aren't I, as an engineer, supposed to be constantly entranced by the bleeding edge of technology? Whether it's the latest lisp Dialect, the latest functional programming language, the latest NoSQL databa…

I'm mixed on this myself. The way I look at it is that since I am more focused on results, I'm always looking for new tools that will do more of the work for me.

That said, I get what you're saying. Often it's clear the new fad doesn't provide much utility. In those cases it's like waiting for a cold to be over.

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

#126

Post by kafkaesq »

webmasterraj wrote: post #108
kafkaesq wrote: post #46

Earlier quoted context omitted.

The thing that helped me, when I felt the indecision paralysis come on, is to just do something and accept that it may be wrong. You often don't know the best decision in the first place because you lack experience. Doing it the right way by accident, or making the mistake of picking the wrong way helps get you that experience. Be deliberate about always doing something, and over time the paralysis will get less and…

Yes, this. I'm self taught -- half the time I'm coding, I don't even know what a "good" approach should be. So I just get started on something, since there's no perfectionist ideal I'm visualizing that I need to hit. The ironic part is that I face this exact problem with the thing I am formally trained in -- writing. The blank page paralyzes me in a way blank vim never does.

That's the thing - we often don't realize what was wrong (or, occasionally, what was actually awesome) about what we're trying to create until after we've put it down not just on paper (or in code), but in front of other people.

It's absolutely intrinsic to the nature of the process. And the best way to virtually guarantee that you won't be ever get to find out whether your idea was good or bad, let alone truly awesome, is... insisting on perfection before it ever gets out the gate.

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

#127

Post by loco5niner »

mikekchar wrote: post #112
CamperBob2 wrote: post #42

Earlier quoted context omitted.

More like tar...

In that line of thinking, I would have to say it's more like dough. At the beginning good dough is very wet and sticky. If you are not decisive with your actions it will stick to your hands, your board, your table, your hair... As you work with it, it creates a workable ball that is dry and elastic. You can shape it with ease, it stretches paper thin without breaking, it rises high and light. The more skilful you are…

You can also use code to _make_ dough.

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

#128

Post by dmarges »

One thing that really threw me for a loop was back when I started learning about TDD. I tried to apply it to literally everything I coded. This caused a lot of paralysis because I was worried about whether I was testing the right way. Over time I came to a compromise. Basically, if I have a good understanding of the design and what I want to build and I know it is going into Production I use TDD. If I'm not entirely sure what I am building or I'm exploring an idea or spiking/prototyping something then I just write the code with little regard for things like speed or design patterns.
Post reply on HN