"Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are."
I'm a good engineer but I suck at building stuff
101–110 of 128 posts
Re: I'm a good engineer but I suck at building stuff
#102Earlier quoted context omitted.
No. It has to be clean, correct, and come with full unit test coverage the first time. You have until the next sprint to implement it. Your workspace is a Macintosh at a long desk where you'll be working shoulder to shoulder with other devs working on other projects. If you can't manage even that, you're just not a good fit for our company; we expected more of an engineer of your experience level. Based on a true sto…
Awesome. I interviewed at one of these once, I knew I wasn't going to get it when I saw the massive imacs and the square glasses... plus the guy couldn't explain what it was they did at all.
I should have known to gtfo when at new-employee orientation I heard a presenter use the word "decisioning" with a completely straight face.
Re: I'm a good engineer but I suck at building stuff
#103A lot of times as engineers we don't have to build anything. We only have to fix, maintain, or tweak. Or maybe build just a very small piece of something. So it's perfectly OK for most of us to suck at building stuff. But on a team it's important someone fill that role. But most of us shouldn't or it would be chaos.
Re: I'm a good engineer but I suck at building stuff
#104> 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…
No. It has to be clean, correct, and come with full unit test coverage the first time. You have until the next sprint to implement it. Your workspace is a Macintosh at a long desk where you'll be working shoulder to shoulder with other devs working on other projects. If you can't manage even that, you're just not a good fit for our company; we expected more of an engineer of your experience level. Based on a true sto…
you have just described a factory construction line.
Not so much: a person not being a good fit for that company. More: that company not being a good fit for long term viability.
Re: I'm a good engineer but I suck at building stuff
#105Here'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.
Your coda is often forgotten, and sometimes "Make it Fast" is essential to making it work.
Re: I'm a good engineer but I suck at building stuff
#106> 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…
No. It has to be clean, correct, and come with full unit test coverage the first time. You have until the next sprint to implement it. Your workspace is a Macintosh at a long desk where you'll be working shoulder to shoulder with other devs working on other projects. If you can't manage even that, you're just not a good fit for our company; we expected more of an engineer of your experience level. Based on a true sto…
What's amazing to me is that devs/engineers are acutely in demand. It's odd that, given this, so many organizations get away with environments that are overtly hostile.
Re: I'm a good engineer but I suck at building stuff
#107> 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 think it's really liberating when you realize that the single most important thing is making it work.
Make it work, and don't succumb to the temptation to worry about what other devs think of your code. The subconscious dialogue that results from that is paralyzing. You can rewrite code n number of times and always believe that n+1 will be better (and it may be).
But, the funny thing is that the eventuality that would objectively make the code better is generally some potential future requirement that is imagined (whether functional or performance). This dictates infintely flexible design and the obsesive hunt for looser coupling. In practice, however, the eventuality seldom comes to pass. This is where the YAGNI principle has some value. Again, make it work.
Re: I'm a good engineer but I suck at building stuff
#108> 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, 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.
Re: I'm a good engineer but I suck at building stuff
#109Here'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.
Make it USABLE. USABLE. Study its USABILITY. The world doesn't need more crummy unusable software.
I use crummy unusable software all the time because it's good.
Re: I'm a good engineer but I suck at building stuff
#110> 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…
Another useful idea is to be not interested (except maybe theoretically) in achieving the best, and concentrating on the good enough.
Sometimes the best is overkill, and a good enough is significantly cheaper (shorter, easier, available already).
Sometimes the best is not good enough, and you have to rethink your strategy.