My module 1 project could’ve gone way better folks.
I started out pretty strong. I knew what I had to do, and I knew how to do it. But my window was short; I had less than 2 days to do the entire project. As the deadline rapidly approached I began to panic, and my work became messier and messier. With only a few hours left, I realized I would only have a half finished project. Or at least, to me it was a half finished project. In reality, I could’ve been ready to go with a prepared presentation and a clean application.
So I’ve been asking myself: Where did I go wrong?
The answer is obvious to everyone reading, right?
I freaked out.
I should’ve started earlier.
I should’ve worked through branches and made concise, sequential additions to my project.
Got it, so next time I’ll just chill out and make lots of branches. Easy. End of blog post, where’s my developer job?
…but that’s just the clarity of hindsight. The reality of being in a situation like that is totally different. While such perspective is certainly useful, it’s not exactly helpful, is it? The unfortunate truth is that it’s very difficult not to work like an idiot in these kinds of situations. It’s also naive to think that you’ll never be under a time crunch; this kind of situation will inevitably happen, and your job could even be on the line.
As with many things in life, we humans tend to follow the path of least resistance, and in this situation it’s absolutely easier to lose your cool and try to rush the project out. So how do we overcome our more basic tendencies and become the cool, collected software developers we dream of being?
We must first become assassins.
…but like, for coding. Really the professions are very similar, here’s a fun table ~
See? Exactly the same.
So how is this actually helpful and not just very weird? Well, that’s the tricky part…
…it IS just very weird.
For a lot of people, it’s totally unnecessary. But some people (me especially) can get stuck in their heads a little bit, and doing something weird and out-of-the-box can correct one’s frame of mind, or help them approach a problem differently.
There have been many, many times (the most recent project included) that I’ve thought to myself :
“If only I’d behaved more like a software engineer, I could’ve solved this problem more easily.”
I (and most of you I imagine) have a bit of an emotional attachment to the idea of becoming a software engineer. That’s not a bad thing, but it complicates things for when I consciously try to act like one. It opens the door to self doubt, and allows something called imposter syndrome to peak its ugly head in.
On the other hand, I’m not very emotionally attached to the idea of becoming an assassin. It’s far, far easier (and more fun) to approach a project like I’m systematically plotting its murder. It’s also a great workaround for dodging imposter syndrome — in fact, I don’t even want to be a murderer (if you do want to be a murderer, unfortunately you may still be prone to imposter syndrome. Sorry.).
How you work has a tremendous effect on the work you do. Things like this may seem silly or irrelevant, but in fact there is nothing more relevant to your work than the way that you approach it. If you find yourself stuck, or doubting yourself, or bored, keep this weird blog post in mind. What’s the harm in trying it out? No one will ever know but you. Besides, as they say…
Testing is free.
- Learn everything about your target
- Passionately plot and scheme
- Execute your plan without passion or fear
- Execute it concisely and directly
- Be systematic
- Use the tools of the trade
- Don’t panic, be patient
- Just work on one thing, then the next
If you can’t make it good, at least make it look good.