8 ms·

The takeaway piece at the end really hit-home for me: I think it’s important to work some fun into programming projects. Give yourself permission to bu

by Alupis 8y ago

The takeaway piece at the end really hit-home for me: I think it’s important to work some fun into programming projects. Give yourself permission to build something that already exists, if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece. And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;) I can't even count the number of similar, fun projects I've started... but which turned into stress centers that felt more like chores than leisure, causing them to never be completed. Often I end up worrying about the "best" way to do something or start planning for when the project is huge and needs to be well formed; paralyzed before I even get the code working.

dceddia 8y ago
Damn, yeah. Same here. That little voice of "is this really the BEST way" has grown stronger and stronger over the years, and I kinda have to fight it back to "allow" myself to do little hacky projects like this. I always wanted to be better at software engineering, and software design, and getting abstractions right, and all that stuff. I've slowly gotten better at all that, but I didn't know it would come with the tradeoff of being unable to switch it off.
- luigi23 8y ago
  Probably thats why many programmers have many great ideas but fails to come into reality. They cannot gain any fun from side project since they automatically want to ‘learn’ new framework, language, etc. Instead of messing around and looking how their idea grows into something fun. Its about having fun from creating, not from learning the proper way since beginning. Its clear when you tell your friends about your new idea - they would say ‘oh thats sounds cool!’, but when I tell the same to my programming friends I would rather hear ‘you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem, so it doesnt make sense’
  - sixdimensional 8y ago
    IMHO, after enough years, it becomes less about wanting to learn the new framework etc. and more about wanting to actually accomplish a specific thing. Put in another way of saying it, when you get tired of the constant pace of change of our toolsets, it becomes more about the problem and solution rather than the specific tool you use to solve it. Don't get me wrong.. I still do love learning all the latest and greatest, and keeping my hands on the tools. But over time, after a long time of getting distracted (or even disrupted by the "need" to keep learning new stuff), I feel at least that it can get tiring and to the point of interrupting any actual productive labor towards a bigger goal. So I agree with you.
    - i_made_a_booboo 8y ago
      You nailed it. It stops being 'wanting to' and starts being 'having to' and that is a subtle inflection point in an engineers life.
- HeyLaughingBoy 8y ago
  That ability to switch it off is very important. A couple months ago, one of my co-workers was asked to do something quickly for an important customer. I would normally be the one to work on that codebase, but I was busy with something else. I gave him some suggestions, made it completely, crystal clear that hacks were allowed since the customer needed it by the next day at the latest and it only had to run for a few hours and we could use the excuse that it wasn't under version control if they wanted changes later. He's a very good engineer and this was well within his ability, but he became hamstrung by the hackiness. He continually complained that it would be unsupportable (I know), that he would be asked to make changes (no: this was explicitly part of the agreement with the customer) and it was a bad design decision (yes!). By the time 4 o'clock rolled around, he had made little progress on his well engineered and future-proof solution and I didn't want to be there late, so I offered to take it from him, finished the hack by 4:30 and pushed it to the customer. Customer loved it; greatly appreciated that "we had dropped all our work to put two engineers on their project" and it did exactly what they needed to demo their own product. I guess my point is that engineering is about getting stuff done. Sometimes, if you know time is more important than anything else, your only choice is either cut corners or don't ship. Being a day late can be the same thing as never shipping in some cases.
  - satsuma 8y ago
    it's one of the biggest weaknesses that engineers/programmers/logical, problem-oriented thinkers have. doing something quick and hacky when it doesn't need to be flawless just feels so wrong. you miss that feeling, that rush when a perfectly-engineered solution just snaps into place and works like magic. and that becomes a problem when it begins to interfere with deadlines, like in your story. i think that's a big part of programming as a career, learning to know when to make something run flawlessly, and when to make it just... run.
    - drb91 8y ago
      Ehh, the problem here seems to be less about logic and more about misaligned priorities in the context of business. There’s a lot to be said about the dopamine rush of making a client happy!
- madeofpalk 8y ago
  Switching it off is how you learn to switch it on better. I started a react project a few years ago and opted against Redux and whatnot. As the project grew and grew it became harder to maintain. Piece by piece, I self identified a 'best practice' that would solve a real problem I had.
  - dceddia 8y ago
    Yeah, fwiw, I am pretty good at avoiding too many shiny toys (though this project might not be a good example of that). I'm all about using React without Redux when it makes sense, and especially at the beginning of a project. Heck, I wrote a whole book teaching React that way, and it's how I learned it myself. Wanting to use the "best practice" libraries is a different angle than what I meant though, which was more like a background thread running in my mind about how I should be refactoring things as I go. Two sides of the same coin though, in a lot of respects.
stephengillie 8y ago
Do stupid things, because sometimes they really do work. And if it's stupid and it works, it's not stupid.
- luigi23 8y ago
  Related: https://www.ted.com/talks/simone_giertz_why_you_should_make_useless_things/up-next https://www.ted.com/talks/simone_giertz_why_you_should_make_...
  - dceddia 8y ago
    Oh hey, that's the girl that makes the crazy awesome robots. I didn't know she had a TED talk. Just Googling and realized she recently had a brain tumor and underwent surgery! Luckily sounds like she's recovering well. https://twitter.com/SimoneGiertz/status/1003470270189858816 https://twitter.com/SimoneGiertz/status/1003470270189858816
- bonniemuffin 8y ago
  I organized a "bad ideas hackathon" at work last year, and it was AWESOME to start with the premise that we were deliberately setting out to build bad ideas. It freed everyone from the shackles of perfectionism, and the teams came up with a whole bunch of devilishly terrible (but working!) projects in a single day. Highly recommended.
RussianCow 8y ago
I think it depends on the purpose of the project. If it's something that you actually want to finish soon, I think this is great advice. Having said that, there is nothing wrong with using a side project as a way to find out what the "best" way to do something is. I personally have an ongoing side project that I will likely never actually complete because I rewrite large parts of it every couple months, but I have learned a LOT about various design patterns, how best to structure code, etc, precisely because I use it primarily as a place to experiment with code. If you don't see the finished product as the end in and of itself, then I don't see anything wrong with that.
burger_moon 8y ago
Because it's frustrating af to read block text on mobile I'm just copying over your pull quote. ---- I think it’s important to work some fun into programming projects. Give yourself permission to build something that already exists,if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece. And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;)
- tome 8y ago
  It's frustrating to read it on the desktop too! Thanks :)
- cyberfart 8y ago
  Not all heroes wear capes.
madeofpalk 8y ago
Something I went through recently was discovering that by doing the 'wrong' thing first - that is, ignoring 'best practices' and doing the 'easiest' thing to achieve the job, you discover the 'best' way more organically. Even if you end up following the same best practices you ignored initially, you are able to appreciate and understand them more.
code_duck 8y ago
I am returning to the development world after 7 years and this has been my problem. I have to decide on what modern packages to use for everything in addition to the usual tug of get it done vs. perfectionism. Like other large tasks, the only way I have found to get hem done sometimes is to just start on a little piece without overthinking. This can be at the beginning or in the middle of the project.

by Alupis 8y ago

dceddia 8y ago

Damn, yeah. Same here. That little voice of "is this really the BEST way" has grown stronger and stronger over the years, and I kinda have to fight it back to "allow" myself to do little hacky projects like this. I always wanted to be better at software engineering, and software design, and getting abstractions right, and all that stuff. I've slowly gotten better at all that, but I didn't know it would come with the tradeoff of being unable to switch it off.

luigi23 8y ago
Probably thats why many programmers have many great ideas but fails to come into reality. They cannot gain any fun from side project since they automatically want to ‘learn’ new framework, language, etc. Instead of messing around and looking how their idea grows into something fun. Its about having fun from creating, not from learning the proper way since beginning. Its clear when you tell your friends about your new idea - they would say ‘oh thats sounds cool!’, but when I tell the same to my programming friends I would rather hear ‘you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem, so it doesnt make sense’
- sixdimensional 8y ago
  IMHO, after enough years, it becomes less about wanting to learn the new framework etc. and more about wanting to actually accomplish a specific thing. Put in another way of saying it, when you get tired of the constant pace of change of our toolsets, it becomes more about the problem and solution rather than the specific tool you use to solve it. Don't get me wrong.. I still do love learning all the latest and greatest, and keeping my hands on the tools. But over time, after a long time of getting distracted (or even disrupted by the "need" to keep learning new stuff), I feel at least that it can get tiring and to the point of interrupting any actual productive labor towards a bigger goal. So I agree with you.
  - i_made_a_booboo 8y ago
    You nailed it. It stops being 'wanting to' and starts being 'having to' and that is a subtle inflection point in an engineers life.
HeyLaughingBoy 8y ago
That ability to switch it off is very important. A couple months ago, one of my co-workers was asked to do something quickly for an important customer. I would normally be the one to work on that codebase, but I was busy with something else. I gave him some suggestions, made it completely, crystal clear that hacks were allowed since the customer needed it by the next day at the latest and it only had to run for a few hours and we could use the excuse that it wasn't under version control if they wanted changes later. He's a very good engineer and this was well within his ability, but he became hamstrung by the hackiness. He continually complained that it would be unsupportable (I know), that he would be asked to make changes (no: this was explicitly part of the agreement with the customer) and it was a bad design decision (yes!). By the time 4 o'clock rolled around, he had made little progress on his well engineered and future-proof solution and I didn't want to be there late, so I offered to take it from him, finished the hack by 4:30 and pushed it to the customer. Customer loved it; greatly appreciated that "we had dropped all our work to put two engineers on their project" and it did exactly what they needed to demo their own product. I guess my point is that engineering is about getting stuff done. Sometimes, if you know time is more important than anything else, your only choice is either cut corners or don't ship. Being a day late can be the same thing as never shipping in some cases.
- satsuma 8y ago
  it's one of the biggest weaknesses that engineers/programmers/logical, problem-oriented thinkers have. doing something quick and hacky when it doesn't need to be flawless just feels so wrong. you miss that feeling, that rush when a perfectly-engineered solution just snaps into place and works like magic. and that becomes a problem when it begins to interfere with deadlines, like in your story. i think that's a big part of programming as a career, learning to know when to make something run flawlessly, and when to make it just... run.
  - drb91 8y ago
    Ehh, the problem here seems to be less about logic and more about misaligned priorities in the context of business. There’s a lot to be said about the dopamine rush of making a client happy!
madeofpalk 8y ago
Switching it off is how you learn to switch it on better. I started a react project a few years ago and opted against Redux and whatnot. As the project grew and grew it became harder to maintain. Piece by piece, I self identified a 'best practice' that would solve a real problem I had.
- dceddia 8y ago
  Yeah, fwiw, I am pretty good at avoiding too many shiny toys (though this project might not be a good example of that). I'm all about using React without Redux when it makes sense, and especially at the beginning of a project. Heck, I wrote a whole book teaching React that way, and it's how I learned it myself. Wanting to use the "best practice" libraries is a different angle than what I meant though, which was more like a background thread running in my mind about how I should be refactoring things as I go. Two sides of the same coin though, in a lot of respects.

stephengillie 8y ago

Do stupid things, because sometimes they really do work. And if it's stupid and it works, it's not stupid.

luigi23 8y ago
Related: https://www.ted.com/talks/simone_giertz_why_you_should_make_useless_things/up-next https://www.ted.com/talks/simone_giertz_why_you_should_make_...
- dceddia 8y ago
  Oh hey, that's the girl that makes the crazy awesome robots. I didn't know she had a TED talk. Just Googling and realized she recently had a brain tumor and underwent surgery! Luckily sounds like she's recovering well. https://twitter.com/SimoneGiertz/status/1003470270189858816 https://twitter.com/SimoneGiertz/status/1003470270189858816
bonniemuffin 8y ago
I organized a "bad ideas hackathon" at work last year, and it was AWESOME to start with the premise that we were deliberately setting out to build bad ideas. It freed everyone from the shackles of perfectionism, and the teams came up with a whole bunch of devilishly terrible (but working!) projects in a single day. Highly recommended.

RussianCow 8y ago

I think it depends on the purpose of the project. If it's something that you actually want to finish soon, I think this is great advice. Having said that, there is nothing wrong with using a side project as a way to find out what the "best" way to do something is. I personally have an ongoing side project that I will likely never actually complete because I rewrite large parts of it every couple months, but I have learned a LOT about various design patterns, how best to structure code, etc, precisely because I use it primarily as a place to experiment with code. If you don't see the finished product as the end in and of itself, then I don't see anything wrong with that.

burger_moon 8y ago

Because it's frustrating af to read block text on mobile I'm just copying over your pull quote. ---- I think it’s important to work some fun into programming projects. Give yourself permission to build something that already exists,if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece. And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;)

tome 8y ago
It's frustrating to read it on the desktop too! Thanks :)
cyberfart 8y ago
Not all heroes wear capes.

madeofpalk 8y ago

Something I went through recently was discovering that by doing the 'wrong' thing first - that is, ignoring 'best practices' and doing the 'easiest' thing to achieve the job, you discover the 'best' way more organically. Even if you end up following the same best practices you ignored initially, you are able to appreciate and understand them more.

code_duck 8y ago

I am returning to the development world after 7 years and this has been my problem. I have to decide on what modern packages to use for everything in addition to the usual tug of get it done vs. perfectionism. Like other large tasks, the only way I have found to get hem done sometimes is to just start on a little piece without overthinking. This can be at the beginning or in the middle of the project.