melreams.com

Nerrrrd

Terrible ironies of programming: people

in opinion, terrible irony, Uncategorized, unsolicited advice

In my last post about the terrible ironies of programming, I foreshadowed the next terrible irony:

Plus being at a computer and away from people is pretty attractive for weird little nerds who aren’t good with people

So many people go into programming thinking they’ll be left alone to code then find out programming is fundamentally a team sport. Even I used to joke that I didn’t decide to work with computers because I like people so damn much (I’ve since knocked that shit off because it’s obnoxious). I’ve come a long way, but I was an extremely shy child. One of the things I love about computers is that they make sense to me in a way that people just don’t. While I eventually came around to the idea that getting people to work together is a really interesting problem, it took over a decade.

But that’s a separate blog post! Let’s talk about one of the reasons software is a team sport: software these days is just too big for one person to build the whole thing and hold it all in their head. I say “these days” like have things have changed since software engineering first became a thing, but the top performers have always been the people who can get their questions answered faster* – it’s just more of an issue now as systems become larger and larger.

You might think that the answer to systems being too large for one person to hold the whole thing in their head is to split them up into microservices, but that just makes the people problem worse. It’s incredibly common for two people (or teams) to have slightly different understandings of what they’re building, and the more interfaces you have with other systems the more likely you are to slam face-first into that problem. Oh and if your microservice only interfaces with one other system, you should be thinking about whether it really needs to be a separate service.

Anyway, the fun thing about people having slightly different understandings of what they’re building is that you think everything is fine until everything is merged and you try to use it and surprise! It’s broken! Wheee! Building to a spec is not that hard. Making sure everybody on both sides of the spec interpreted it in exactly the same way is that hard.

Also like I said in my last terrible irony post, humans just kinda suck at programming. We need each other’s help constantly. Even if you never speak to anyone outside of your dev team and manager, you’ll still have to talk with them constantly. The lone programmer in a basement office may have been a thing in, like, the 80s, but the 80s are over, man (in case that link stops working, it’s the scene from Formula 51 where the state trooper tells Samuel L Jackson’s character that “the 60s are over, man”).

Even then, programs were getting too big for one person to know everything and even then the top performing programmers were the ones who a) knew who to ask when they had a question and b) were nice/known enough that the person they needed an answer from would get back to them in a timely manner instead of whenever they damned well felt like it.

I’m not convinced there has ever been a time where programmers didn’t need to talk with other people, we just wish there was because a lot of us nerds fantasize about being left the hell alone to code. I’m not even saying I’m not one of them, one of my favourite coding days in recent memory was when I got to put my headphones on and spend a day banging out a Python script to parse a particularly uncooperative set of log files and not talking to anyone. The thing is, that’s the exception, not the rule. As uncooperative as those log files were, they were based on an extremely detailed spec and once my tech lead told me which characters should be parsed into which field, I was good to go. Normally software isn’t nearly so well defined.

And anyway, that’s just between devs. If you have a separate QA team you need to talk with them too, both to make sure they understand how to test any given ticket and to make sure you understand what’s wrong when a ticket fails QA and comes back to you. If you have a product owner or product manager you’ll need to talk with them a lot to make sure you’re actually on the same page.

One of my big fuckups at a previous job was getting together with another dev and our manager and deciding without the PO that integrating our project with a certain existing feature we knew a big client wanted the new feature to work with was just not going to happen. Yeah it turns out that feature was a massive part of that company’s business and there was no point building the new thing if it could never work with that particular existing thing. Our poor PO sure loved that surprise when she looked at my edits to the internal wiki page for that project. There’s plenty of blame to go around on that one but as the acting team lead on that project I should’ve known better than to make a decision that far-reaching without the PO.

If you’re doing any frontend work talk with your UI/UX/designer too! I haven’t done much UI lately but even I know it’s important to be on the same page as the designer. You need to make sure you understand what the design is meant to accomplish, not just what elements you see on the wireframes or mockups. And show your designer your progress as you work through the ticket, that can uncover misunderstandings you didn’t think to ask about.

Don’t forget showing your work to actual users too. Nothing you build matters if nobody can figure out how to use it if they even wanted to in the first place. Coast Capital’s old useless activity log, I’m looking at you. I promise you it’s okay to display table data in a fucking table, you don’t have to show me almost nothing and make me click on things over and over to get any details. Also if you’re going to display a small and largely useless subset of data that appears in another report, just add another filter option that report. Between design and implementation that activity log burned at least a week of time that neither the designer or developer is ever getting back.

Your application doing the wrong thing very quickly and accurately isn’t actually useful at all. It’s not useful either if everyone hates it so much they just won’t use it. Coast Capital’s old  nearly content-free activity log, I’m looking at you again. You really do have to talk to people to build anything meaningful! Even if you build a small app all on your own and can hold the code in your head, you still need to talk to your users.

The extra fun part is that even if you personally accept that you have to talk to people to get shit done, you’re probably working with people who haven’t accepted that yet and you’ll have to pull teeth to get them to tell you wtf they’re up to, wtf their problem is with your code (ask me how much of a disaster code review can be, I dare you), and why the hell they did it that way when you told them already what you were planning and now nothing works because their part doesn’t integrate with your part correctly.

And that’s assuming everyone you work directly with shares your goal of producing realiable software that makes users’ lives a little bit easier. I have another blog post coming about coworkers who couldn’t give less of a shit about users, the company, their coworkers, or anything except getting their way.

* The Psychology of Computer Programming, Gerald M Weinberg. I’m entirely too lazy to look up the page number but I swear it’s in there.

Link of the day

in link of the day, opinion, selfcare, unsolicited advice

Persistence is enormously valuable, I even believe it’s more important than intelligence if you want to a programmer, but knowing when to quit is valuable too. That’s why I like I successfully chased my Big Life Dream, and I hated it by Rowen, so much.

Their dream was to travel the world in a sailboat, yours might be to become a freelancer, to start your own business, to switch to game development, or something else entirely. If you try something and it turns out to make you miserable, it’s okay to stop and do something you actually like. I’ve read a lot of sad stories about people who made themselves miserable, put themselves under so much stress it wrecked their health, or financially ruined themselves pursuing a dream that just wasn’t working, and I really don’t want that for any of my readers.

On a lighter note, if you do New Year’s Resolutions, consider quitting something you don’t actually like instead of trying to squeeze more and more activities into your life. If that feels selfish to you, think of it as setting a good example for others :)

Be a better programmer while still having a life: part 9

in becoming a better programmer, best practices, career, development, making stupid arguments look stupid, unsolicited advice

brown wooden wheel on an old cart with fallen leaves around it on the ground.
Vaguely related image from pexels.com to make this post look nicer in social media shares.

Don’t reinvent the wheel! I’ve touched on this before, but it definitely merits its own post.

A huge part of becoming a better developer is understanding when you don’t need to write new code to solve a problem. The more code you write, the more code you have to maintain, the more chances you have to screw it up, and the more time it takes to write it. So before you write new code, see if there’s a library, a plugin, a product, a design pattern, or a best practice that solves your problem. At least see if anyone wrote an article or blog post about a similar problem and learn from what they did.

To be fair, sometimes what you need really isn’t well served by an existing trustworthy product or library and you do need to write your own custom code, but that needs to be an informed choice, not a reflex.

What I think makes a product trustworthy is active development and a large userbase. The main advantages of using a library instead of writing your own code is that you don’t have to update it and that most of the bugs have been worked out already because so many people use it. By all means use a small library that isn’t maintained if it’s convenient and not a core part of your project, but for the love of god don’t depend on a framework/database/core part of your project that isn’t actively maintained and/or doesn’t have any users. That will just end in tears.

You also don’t want to import a library for every little thing, the more libraries you import the more bloated your project becomes and the more chances you have to run into a bug in one of them (and let’s not forget the left-pad debacle), but for stuff that would take more than a few hours to write, see if somebody else already wrote it.

For example, writing your own regex to validate email addresses is almost certainly a waste of time. Are you really going to write a better validator than the Apache Commons EmailValidator? No, you’re not. And do you want to have to maintain it forever even if you do write a great validator? No, you don’t. So use the library and move on with your day.

Yes, writing code is way more fun than integrating a library, but when you’re at work your job is to get results. If writing your own code gets the best result, do that, but if integrating a library gets the best result, do that instead. Of course, to understand what gets the best results, be it a library, a whole product, an API, a design pattern or whatever else, that means you have to understand what’s out there.

As a bit of an aside, that’s why the Google bro is an incompetent engineer – his ridiculous screed shows he either didn’t read or didn’t understand any of the existing research about personality differences between men and women (spoiler: there aren’t any statistically significant ones). While junior engineers get a pass on not searching for or not understanding existing libraries, senior engineers do not. If you can’t Google (see what I did there :D) existing research or existing libraries, you simply are not operating at a senior engineer level.

Sometimes it is useful to reinvent the wheel – modern wheels with inner tubes and shock absorbers make riding in a modern car a lot more comfortable than riding in the first cars with their solid wheels (Google bro’s wheel, on the other hand, is square and the axel is off center, which is just embarrassing). If you can’t do better than existing wheels, just use what’s already out there and save yourself some time.

Ironically, admitting that you aren’t the greatest developer who ever lived makes you a better developer. Accepting that actively maintained, well-used libraries are often better than what you would write on your own not only saves you a lot of time, but also makes your final product better.

Repetition is underrated

in development, learning, opinion, unsolicited advice

a brown-skinned woman wearing a dark blue top and a white skirt plays an electronic keyboard
Loosely related image from pexels.com to make this post look nicer in social media shares.

The more I read about the struggles beginner programmers have and the more I mentor at Ladies Learning Code workshops, the more I think that repetition is seriously underrated when it comes to teaching anything technical.

When you’re learning a language or an instrument or a sport or a physical skill like plumbing or carpentry or even math, which is similar to programming in a lot of ways, you expect to have to repeat the same thing multiple times before you remember all the details and get it right every time, but somehow when you’re learning to code we assume you should only need to be told how a for loop works once and you’ll understand it perfectly right away and remember it forever. That’s just not how our brains work and that’s why I think repetition is so underrated.

It is completely normal to need to write a lot of for loops before you get it right every time. Some people do pick up programming concepts very quickly but that doesn’t mean you’re dumb or abnormal if it takes you longer. Something like a for loop (or anything programming construct) seems simple once you understand it, but there are actually an enormous number of fiddly little details you have to keep track of to get your loop to work. You know what’s a great way to learn all of those details so thoroughly you hardly even think about them anymore? That’s right, repetition!

Programming isn’t just a matter of understanding the concepts, you’ve also got to learn them so thoroughly you don’t have to think about how to write a loop, you just write one when you need it. Without that thorough of an understanding, programming is like trying to speak another language by looking up each word individually in your [other language] to English dictionary. That’s one way to learn, but you’ll probably just be miserable and frustrated and forget what you were trying to say in the first place before you’re even halfway through your sentence.

Come to think of it, maybe the kind of drills you do when you’re learning a language could help people learn to program without spending so much time worrying that they’re just not smart enough.

Anyway, repetition is seriously underrated and I wish we collectively talked more about how much practice it takes just to pick up the basics of programming, let alone the complicated stuff like deciding how to structure your code or what to name things (still one of the hardest problems in programming :) ) I think a lot of programming tutorials assume that you know you need to practice without explicitly saying it or without making it clear just how much practice you need. I have to admit I wouldn’t want to write pages and pages of very similar programming exercises either, but it’s not so hard just to say that programming takes practice and you’ll probably need to go through the tutorial a few times before it sticks.

If you did a tutorial or a workshop just once and didn’t instantly become a good programmer, congratulations, you’re normal! If you keep at it, you’ll get there.

Resume advice

in career, resumes, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.

The academic year is ending pretty soon and students are probably starting to look for co-op jobs, so hey, why not throw some unsolicited resume advice at people?

First a quick disclaimer, I help review resumes now and then but I don’t have a huge amount of experience with it. Some of the stuff I’m going to tell you is stuff I’m really sure I’m right about, and some of it is just my opinion.

My first piece of advice, and the one I’m the most sure about, is proofreading. Proofread your resume! Put it away for a little while (at least a few days), and proofread it again! Get a friend to proofread it! Get your parents to proofread it! Go to your school’s career center and get them to proofread it! Wow, the word proofread looks really weird when you use it that much :)

But seriously, proofread! Why am I harping on that one so much? Because a resume with mistakes on it shows you aren’t good at fiddly little details. That’s a serious problem because programming is fiddly little details. Compilers and IDEs and syntax highlighting text editors can help you catch a lot of bugs, but they can’t catch logic errors for you. To find and fix logic errors, you have to pay really close attention to the code and keep track of every little detail. If your resume has mistakes, that makes me very worried that you’re going to struggle with programming in general and logic errors in particular and honestly, that’s going to make me very likely to set your resume aside. I say “very likely” because it is possible that if you had some really great projects on your resume I would still consider your resume, but you know, it’s a lot easier just to proofread the hell out of your resume :)

On top of making me worried about your ability to program, having mistakes on your resume just looks sloppy. That’s really not the first impression you want to make on a potential employer. In school it’s not as big of a deal if you lose a couple of points for having a typo or an autocorrect fail, but when you’re applying for a job that’s very likely to take your resume out of consideration entirely.

My next piece of advice is detail. Almost no one has too much detail on their resume, you basically can’t go wrong if you add more detail about exactly what you did, especially on projects you did as part of a team. When I’m looking at a resume, I want to know what you did. If you were involved in every part of the project, just say that instead of letting me wonder what you actually did. If you just did, say, the back end part of the project, say that! If I’m looking for a back end dev, I want to know if you have back end experience.

This one’s a little more subjective, but personally objectives on resumes take up space that could be used to tell me something more interesting. I mean, I know you want to work on software, it would be pretty dumb to apply for a dev job (co-op or otherwise) if you didn’t. That said, I’ve heard from other people that objectives make it easier to keep track of which position someone is actually applying for, which can be really handy if you don’t use an applicant tracking system and have a pile of resumes you’ve printed out. Basically, go ahead and include an objective if you want to, but don’t feel that you have to just because your teacher said so.

Job history is a tough one for students especially, I have two pieces of advice for you there. One, it is totally okay to have a projects section on your resume if you don’t have a lot of relevant work experience. Heck, even if you do have a lot of relevant work experience, if you have projects you’re proud of have a project section on your resume! Opinions differ on this one, but I think it’s perfectly fine to include school projects on your resume. What else are you supposed to do if you’re a student?

Two, you do not have to list every crummy summer job you’ve ever had. Especially if you took breaks from school to work to pay for your next semester, you do not have to use up half a page listing every retail/hospitality/whatever job you’ve ever had. If you took breaks from school to work it’s not a bad idea to explain that in your cover letter, but I’d much rather hear about cool projects from your classes than about stint #4 at $FastFoodPlace on your resume.

Readers, do you have any advice for students or anyone who doesn’t have years of dev experience to put on their resumes?

Be a better programmer while still having a life: part 8

in becoming a better programmer, development, opinion, productivity, unsolicited advice

The big tip for post #8 in the be a better programmer while still having a life series is to become a witch. A Terry Pratchett style witch, to be precise. Terry Pratchett’s witch characters are really great at two things: first sight and second thoughts. To quote him directly:

First Sight and Second Thoughts, that’s what a witch had to rely on: First Sight to see what’s really there, and Second Thoughts to watch the First Thoughts to check that they were thinking right.

And no, I’m by no means the first person to connect Pratchett-style witchery with programming or design. Hint: go read that blog post, it’s really good.

Back at my original point, first sight is seeing what’s actually there, not what you wish was there or what you thought was there or what you meant to put there. Does that remind anyone else of debugging?

Fortunately for programmers, we have tools like debuggers and IDEs to help us see what’s actually there. We also have techniques like simply getting up and taking a walk, or explaining our problem to a rubber duck (or maybe another programmer if it’s a really hard problem), or commenting out half of our code and then half of that half and so on until we find the problem line. Let’s just not think about how much programming must have sucked in the days before friendly IDEs that highlight mistakes for you :)

Unrelated image from pexels.com to make this post look nicer in social media shares.

Another part of first sight for programmers is also your attitude. If you don’t want to see the problem, you’re just not going to no matter how observant you are normally. I’m by no means perfect at it myself, but I’m convinced the most useful attitude you can bring to debugging is the simple acceptance that you got at least one thing wrong. The longer you spend insisting that your code should work, the longer it takes to figure out what’s actually wrong with it.

Moving on, second thoughts are thoughts about your thoughts. When you think you know the best way to build something, why do you think that? How do you know you’re right? Is that actually the best way or is it just the first way you thought of? How would you know either way? What constitutes the “best” way to do something? Is “best” the most performant, the easiest to read, the easiest to change, the quickest to write, the easiest to test? If “best” for your project meant quickest to write yesterday, does it still mean that today? How would you know when that changes?

Checking up on yourself like that is really hard to do and that’s why this post is more for me than for you – I’m trying to remind myself to question my assumptions.

One of the traps I fall into most often is looking for an example of what I want to do in our existing code and then assuming the first thing I find is the right way to do it. Shockingly enough, codebases change over time. Just because something worked well when it was written doesn’t mean nobody has thought of a better way since then or that the rest of the app hasn’t changed enough to make the old “right way” completely different from today’s “right way.” Just like you look for a couple of sources that agree with each other when you’re Googling what an error message means, look for a couple of examples in your codebase and if they’re different, check which one is newer.

Getting into the habit of thinking about how you think is not easy (at all!), but it’s useful and, like the other installments of this series, not something that you have to devote all of your free time to. It’s also useful in pretty much every area of your life. When you have any problem to solve, how do you know you’re right about how to solve it? For that matter, how do you know you’re right about what the problem is?

When I’m stressed out, every little thing drives me absolutely crazy. I can end up convinced that what’s bothering me is that this stupid freaking feature won’t work no matter what I do when the real problem is that I’m trying to hit a tight deadline and marketing keeps changing their minds about what’s important and half the QA team is sick so they need extra time to test everything and that means I need to deliver even sooner and everything is terrible!

Okay, so what do you do about that? For starters you really should read that blog post I linked earlier, Amy Hoy goes into a lot of detail about learning to notice yourself thinking. My big tip is just to get into the habit of asking yourself “Why? Why did I decide that? Why is that the best way? Why is that bothering me so much?” Sometimes the answer is going to be stupid simple: I decided to go to cafe at the front of my building for lunch because the weather was hideous and I didn’t want to go outside. Sometimes the answer will lead to more questions, like when you ask yourself “Why did I decide to put that config file in that directory?” In my case the answer was “Because that’s where the other config file lives” which leads to another question: “How do I know both config files should go in the same directory?” From there I learned all sorts of stuff about which files were supposed to go in the original directory and why, and where the other file that was related but not the same type of config ought to live.

This is the kind of thing that takes a lifetime to master, so don’t feel bad if you don’t get it right away. Asking yourself those questions is still worth it even if you only remember to do it sometimes.

The wall

in becoming a better programmer, development, learning, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.

I was talking with a friend who’s learning to code the other day, and the subject of the wall came up. Not the one that keeps the wildlings out, the one everybody slams into when they’re learning to code. Learning to code starts out great, there are so many tutorials that break things down really clearly, but once you’ve got a handle on the basics and want to move on to building your own projects, that’s where you hit the wall. It’s a huge leap from following tutorials where all the hard decisions are made for you to building your own projects with no one standing by to tell you where to start or what database to use or what your UI should look like.

The single thing I most want you all to know is that hitting the wall is normal. It happens to everyone. It absolutely does not mean that you’re dumb or not meant to be a programmer or that you’ll never get over the wall.

As a bit of an aside, I think the number of beginners who hit the wall and assume they’re just not smart enough to be programmers says more about how bad we collectively are at teaching programming than about the intelligence of anyone who hit the wall and walked away. I’m suspicious there’s a connection between how easy it is to write total beginner tutorials and how many of them there are, and how much harder it is to teach people to break down a problem and how few tutorials there are for that.

But anyway, I have some ideas for people who have hit the wall or who can see it in the distance and are getting worried.

One of the coolest things about programming is how many open source projects there are. Find one that you like and take it apart to see how it works. Search for text from the UI in the code and see if you can change it. Throw log messages all over the place to make the code show you what it’s doing. See if you can find some constants in there you can mess with. And don’t feel left out if you want to make games, those can be open source too.

Once you’ve found a project you like and have some idea how it works, see if you can change how it works. Let’s say you found a simple todo list app. Can you add due dates to your list items? Or subtasks? Could it play a sound and/or an animation to congratulate you when you check something off? Could you add a new feature like recurring tasks or email reminders? If you don’t have an open source app handy, just take a tutorial and mess with that.

Speaking of tutorials, if you do enough of them you’re going to start seeing similarities. Most apps have some sort of UI, some sort of data model, maybe a way to save that data for the next time you open the app (that’s pretty advanced, though, don’t worry about it right away), some logic about what users are allowed to do (like due dates can’t be in the past or players can’t have more than x hitpoints no matter how many health packs they use), maybe some communication with other APIs (but again, that’s advanced, don’t worry about it right away), and honestly, that’s pretty much it.

You can try mashing up different tutorials or open source projects too. Let’s say you have a tutorial for a driving game and one for a game where you run around and collect coins or stars or whatever. What if you could drive around and collect stars? What if you had tutorials for a todo list app and a weather app and mashed them up to make a little morning dashboard for yourself?

Don’t forget, you don’t have to do it all yourself. There are great communities like CodeNewbie, /r/learnprogramming, CodeRanch, (and lots more if you do a little Googling) full of people who will help you out.

Hiring funnels are a thing

in career, hiring, interviewing, looking for jobs, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Recently I went to a Victoria BC Startups meetup about diversity and inclusion in recruitment called Lever talks Diversity and Inclusion in Recruitment. What I learned the most about was how hiring funnels work.

I first learned about the concept of funnels from sales funnels, where you start at the top with lots of people who are simply aware your product/service exists, and work your way down through getting them interested in your product to making a decision about whether to buy to eventually making a sale, with fewer people at every level. That’s normal for sales (and for any other funnel, like hiring), not everyone who is aware of your product is going to want it. Many of them may not even have a problem your product solves. Some people go with competitors, some people just keep doing what they’re already doing, some people are ready to buy but at the last minute they lose their budget or their boss decides to change direction, all sorts of things happen. Because of that, you need a lot of potentials at the top of the funnel to make sure anyone makes it all the way down to the bottom.

Sounds a bit like hiring, doesn’t it? ;) The big difference with hiring is that you either need to get people into the top of the funnel before you have an open position for them or you need to fill that funnel up extraordinarily quickly once you do have that open position.

The big thing I learned about that is that lots of people don’t think exactly like me. I’m sure that’s all kinds of helpful :)

More precisely, what I learned is that it’s normal to start talking with people before you actually have a job to fill and that doesn’t make you a time-wasting jerk as long as you’re honest about not having an open position right then.

The reason I had so much trouble with that idea was because I don’t usually bother talking to other companies until I’m Capital D Done with my current company and am actively interested in a new job. Since I thought that way I assumed everyone else did too, and because of that I figured talking with potential hires about a job that didn’t exist yet would be a mean-spirited waste of their time. I mean, they could have been talking with someone else about a job that actually existed and started making real progress toward their goal of finding a new job instead of wasting time on maybes with me. I’m not saying it was perfectly rational to be that worried about wasting people’s time, just that it was a thing I worried about.

But apparently it’s also normal for people to start talking to other companies well before they reach the Capital D Done stage, which makes it not a jerk move to talk with them about a job that doesn’t exist yet – as long as you’re clear about the job not existing yet, of course. I’m harping on that point because I feel very strongly about not jerking people around and because that’s the big thing that makes talking with people without having a job opening to interview them for work for me – I have to know I’m not jerking them around or I just feel weird about the whole thing.

Honestly, it’s probably smarter to start looking around before you desperately need a change, but the flip side of my not wanting to waste candidates’ time is that I don’t want to waste hiring managers’ time either. I assumed they only started talking with people because they had a job they needed to fill, which would make it a waste of their time to talk with them before I was sure I wanted to leave my current job.

I never really thought about how much time it takes to fill a hiring funnel (have you ever tried to hire an experienced developer in Victoria? It’s hard!), so I never realized how useful it actually is for hiring managers to have some people already in the funnel. If you have that then when it’s time to hire you don’t have to start from scratch, you can interview people who you’ve already talked to, who you already think could be a fit, who are already interested in your company. That sounds pretty great if you’re looking to hire, which makes it not at all a jerk move to talk to hiring managers before you’re sure you want to change jobs – again, as long as you’re honest.

In short, the moral of the story is that not everyone thinks the exact same way you do and that as long as you’re honest about what you have to offer you’re not being a jerk :)

Trick yourself into getting stuff done

in development, opinion, productivity, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

You know that feeling when you need to get something done and you just don’t want to? Considering this post was published on a Monday, I bet you do :)

When I don’t feel like doing something, I find it can really help to trick myself. That is, I do a tiny little piece of something that’s related to the thing I need to do but that I can tell myself isn’t the real work. For example, if I’m starting a new feature, I might tell myself I’m not really starting it yet, I’m just poking around in the existing code a little and seeing where I could put it if I actually was starting that feature. Or I might tell myself that I’m not really building that feature, I’m just stubbing out a class and writing a few comments about how I would build if it I were doing that, but I’m totally not, I’m just writing comments, nothing to see here ;)

Minus a certain amount of flailing around trying to figure out the best way to do something, this is basically my process when I’m building stuff:

Don’t do the thing, just poke around in the code a little.
Don’t do the thing, just make notes about what you find.
Don’t do the thing, just write down ways you could do the thing if you were going to (but you’re not).
Don’t do the thing, just stub out a class (if needed) where you would do the thing.
Don’t do the thing, just write some comments where you would do the thing.
Don’t do the thing, just stub out a method.
Don’t do the thing, just pseudocode one method.
Don’t do the thing, just fill in one method.
Don’t do the thing, just write down one thing you’ll need to test.
Don’t do the thing, just pseudocode one test.
Don’t do the thing, just fill in one test.

Honestly, that’s the core of software development. Software design and architecture are certainly important too, but I’m convinced the single most important part of actually building stuff is breaking down problems into manageable little pieces. If we had to think about the entire application all the time, we’d all end up under our desks weeping quietly. Only the ability to ignore the big picture for a while and focus on one tiny piece allows us to actually get anything done.

Of course just because “break the problem down into tiny pieces” sounds simple doesn’t mean it’s easy. It’s really common to get side-tracked trying to figure out how something unrelated works (I have the worst time leaving stuff alone even it’s probably not relevant to what I’m currently doing), or to spend far too much time trying to figure out what the best way to do something is (that one’s so common we have a word for it), and sometimes you just don’t know where to start or the problem has so many moving parts that you feel overwhelmed and quietly freak out a little.

On the upside, learning to break problems into manageable pieces gets easier with practice. For me it’s mostly a matter of reminding myself that I’ve done this plenty of times before and I’ll solve this problem too.

If you’re having trouble getting started, see if you can trick yourself into doing something. Remember you don’t have to solve the whole problem at once, you can start with a tiny piece of it.

There’s always something else to learn

in development, learning, opinion, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Not long ago I read this blog post Why Learning to Code is So Damn Hard, which makes a really interesting point about the “desert of despair” between beginning to learn to code and having the skills to build a complete project on your own. The desert of despair, according to the post (which I agree with) is a combination of lack of resources for learners who are between beginner and expert, and having learned enough to know how much you still have to learn. Many aspiring coders get lost in the desert of despair and never find their way out.

I also read Amy Hoy’s post 5 Things I Wish Somebody Told Me Before I Founded My SaaS. One of the points I found the most interesting was that there’s always another inflection point. By inflection point, she means “those knife-edges you tip toe along, when things could go either way, when you are, say… trying to grow your team but lack the time/revenue to do it, but growing your team would help increase the time/revenue to the point where you could grow your team. Ouch. To me, that’s the prototypical inflection point.”

Where this ties back to the other post is where Amy says “Over the last 8 years running this biz, I have said so many times: “We just have to get through this $INFLECTIONPOINT and then things will get easier.”” Doesn’t that remind you of programming?

If I can just learn enough to get my code to compile then things will be easier.
If I can just learn enough to add a feature to an existing project then things will be easier.
If I can just learn enough to start a project on my own, then things will be easier.
If I can just learn enough to break my code down into good methods, then things will be easier.
If I can just learn enough to break my code down into good classes, then things will be easier.
If I can just learn enough to break my code down into good layers, then things will be easier.
If I can just learn enough design patterns, then things will be easier.
If I can just learn this new framework, then things will be easier.
If I can just learn this new style of programming, then things will be easier.
If I can just build enough different projects, then things will be easier.
If I can just learn enough…

There’s always going to be something else to learn, it’s never going to become easy and stay that way. Things do get easier once you find your way out of the desert of despair, but initially learning to code just leads to worrying about whether your code is good leads to worrying about design and architecture and scalability and reliability and security and those are seriously hard problems.

Despite how it may sound, I’m actually not trying to say that coding will suck forever and you should just give up. I’m saying that it’s normal to feel like you still suck at this even after years of working as a programmer. You don’t actually suck, it’s just normal to feel that way. What’s really happening is you’ve levelled up. When you do that you see the problems that used to give you trouble as too simple to count and focus on the stuff you aren’t good at yet, which can easily make you think you suck.

The thing I struggle with is design. I’ve been at this for ten years now and I’m still never sure if I’ll regret the design I’ve come up with the next time we add a feature to the system. Plenty of times I’ve come up with something that seemed like a good idea at the time, only to find out that it had serious flaws when I came back and changed it later.

It’s tough sometimes but on the upside, you will never ever run out of things to learn as a programmer :)