For the first time in my career, I recently got to sit in the hiring chair. My current employer let me look for a Software Engineering Intern. (With a little luck, I'm hoping to repeat the process for a senior level developer in the near future.)

I learned a lot, very quickly, doing that (a biggie: actually write down a list of questions to ask, don't just wing it—with my apologies to the very first person I interviewed, as I did not do a good job interviewing you), but this post is not about those lessons learned. This post is for all the people I had to send a rejection letter to. In my opinion, all of the people I interviewed were smart and capable of doing the job; actually picking one was a tough choice.

While our chosen field of computer programming offers amazing opportunities, finding work can be difficult¹, so don't despair. Here are some general tips to help you find work, and become a better developer.

Caveat: These are all filtered through my path as a developer, which absolutely does not match yours. The most obvious and major difference being I did not go to college. Props on going for the degree!

Finding Work

Give Talks

Local user groups—such as DSM Web Geeks, Pyowa, DSMJS, Iowa Ruby Brigade, CIALUG, and so forth in the Des Moines area—are always desperate for talks, as are larger conferences such as Iowa Code Camp. Too many people are terrified of speaking, thinking they need to be an expert, but that's just not true. The perspective you bring as a newbie, showing us all something you've learned, is both incredibly valuable, and woefully under-represented. It's also an effective way to catch the eye of a hiring manager or recruiter.

Giving talks will help you become a better communicator, which is a vitally important part of being on a team.

Contribute to Open Source

I learned a ton in my early days by contributing to open source projects. If you can find a project you care about, with a community of smart, patient people willing to help guide you, contributing to existing projects will help make you a better programmer, and give you things you can point at to say: I did that.

Contributing to open source will help you get better at revision control (e.g., git), reading code, and accepting feedback.

Develop Your Network

Getting your foot in the door of a place is a lot easier if you already know somebody on the inside. Be friendly, hobnob with other developers (e.g., at local dev groups), and stay in touch with people.

I've spent large chunks of my career as a lone developer and am a natural shut-in, so this is one area I regularly fail at.

Expand Your Mind

While learning the Framework Du Jour or a specific technology will help you be more employable in the short term, a solid foundation of knowledge will help you throughout your career, enabling you to pick up framework and language specifics more quickly, and to see the similarities with things which have come before.

While it'd be difficult to point you to the books that helped shape me as an early developer—in part because books like "QBasic For Dummies" and Laura Lemay's "Teach Yourself HTML 4 in 21 Days" would be a tad anachronistic at this point (though it appears there is a more modern version of the latter)—I can at least point you to some that have shaped me as a more intermediate developer.

How to Design Programs
This book is a gentle introduction to programming. It's a solid look at programming starting from zero. While you're almost certainly beyond it skill-wise already, I've been skimming through it lately and find the way it frames things can be helpfully clarifying.
Structure and Interpretation of Computer Programs
This was the textbook for an MIT course of the same name for a long time, and takes you from basic functions to meta-circular evaluators. Depending on what you've been exposed to already, it may well cover a gamut from "yeah, duh", to blowing your mind. Also freely available online as a textbook, and video lectures.
Practical Common Lisp
Common Lisp is a really fascinating language, and can open your mind to possibilities you likely haven't imagined. It certainly did for me! As just two examples: multiple dispatch and the condition system are among the things I sorely miss in other languages. Also available freely online.
Coders at Work
This book is a series of interviews with influential developers. It's an interesting foray into the minds and experiences of people who have ventured down the path of software development you are just now beginning to embark upon. This one isn't freely available, but it is a fascinating read, in my opinion.

Admittedly, that list reflects a heavy Lisp heritage. Lisp has had a heavy impact on me and the way I think about programs, but many languages can fall under the category of "mind-expanding". You're likely already familiar with Java, which covers the space of modern, standard object-oriented design. Some other design spaces you may want to explore, if you haven't already:

  • A purely functional language. Purely functional code is often easier to understand and test than OO code, and you'll see its influence across a broad spectrum of languages. A good way to explore this space is through Haskell, which is a very mathy language—you could easily get lost in monads and category theory—, if you're into that sort of thing.
  • Different concurrency models. Erlang's actor-based concurrency model is fascinating, and often much better suited to problem domains than thinking about lower-level things like threads and mutexes.

Sadly, none of these things are likely to make you more employable on paper—a sad reality of how we evaluate developers today—but they will make you better at the job itself.

Be Well-Rounded

It took me entirely too long to learn, but there is more to life than slinging code, so don't forget to do things that aren't programming. Take an improv class, learn some ballroom dancing, learn about user experience (UX). Whatever interests you.

  1. I am amazingly terrible at interviews, to the point where I've spent years in between jobs, and the jobs I've gotten are often in spite of my interview. I totally get how frustrating it is to be rejected.

That's kind of a provocative title, so let me just get this out of the way: No, no they are not. And I am not crazy enough to attempt to convince you otherwise. That said, they aren't nearly as bad as they're given credit for.

Let's do this by way of example. Suppose you have a list, and users need to be able to sort it, alter the items in the list, and delete items. All your front-end developers are busy, and so are the UX people, so it's up to that backend developer to bang something out. What are they going to give you? Something, I suspect, an awful lot like this:

Sort Item Delete?

In other words, a <table> that closely mimics the underlying database structure. Yeah, I can hear the internal screams of the UX people from here. But let's consider this for a moment. Is this going to be fun to use? No. Definitely not. But in its straightforward simplicity, it gives us something that's kind of amazing: anybody can use this form. No matter how spotty your network connectivity, if you managed to load this form, you can submit it. If all you have is a text-only browser, you can use this form. No mouse? That's okay, this form is keyboard-accessible. Do you interact with your computer via voice command? This form will be serviceable.

For the vast majority of your users, this is not great UX. But it is Universal UX. Anybody―everybody―can use it! The web is universally accessible by default, and by staying away from the fancy stuff, by building something that would be at home in 1994, our backend developer managed to preserve that.

We definitely don't want to stop here, but it's a pretty great jumping-off point. So let's put our UX hat on and start making some improvements.

Sort Item Delete?

Some quick wins are simply to adjust the sort values to make rearranging easier, and adjusting the text of the button. Not terribly complicated, even the backend developer can manage it.

Sort Item Delete?

But of course, manually entering the sort weight is awful, so maybe we add some buttons to adjust the list sorting, so users can click a button, rather than type in sort values, and hide the numeric input with a little CSS. We'll leave it in the DOM both for text-only browsers, and to give a place for our buttons to store the sort order (assuming they function via JavaScript).

Sort Item Delete?

And as we get fancier, maybe we dim or strike-through the to-be-deleted rows, to make it obvious they're going to go away. We add a little JavaScript to enable drag-and-drop of the rows, for really simple sorting. Maybe we even add some keypress handlers so people can move things in the list by pressing C-x C-t or whatever seems appropriate. And if those scripts load successfully and work in the user's browser, maybe we even hide the explicit sort buttons from visual users, to avoid clutter. You do run the risk of excluding a small contingent of users that way―if you can only interact with a computer through eye-movements, visible buttons might be kind of handy―but for all I know they may have other ways of handling that, so if you've got the budget, maybe test that sort of thing and report back to the rest of us. I'd certainly love to know.

But in the end, what we end up with is a lot closer to what you might have designed as a visually-oriented UX person, but because we built it in stages, because we started with the basics and layered things on top, it's usable in far more scenarios than it might otherwise be had we started with a Photoshop mockup of the end result.

NB: As you may have noticed, there is no JS attached, and there isn't much in the way of styling. That's partly due to platform limitations, but mostly because this isn't really meant to be about how-to-build it, but more about what-to-consider in the design. It just so happens that if you build it in a certain order, those considerations naturally reveal themselves.

November 2021

S M T W T F S
 123456
78910111213
14151617181920
212223 24252627
282930    

Syndicate

RSS Atom

Most Popular Tags