melreams.com

Nerrrrd

Showing up is my secret superpower

in career, opinion, unsolicited advice

Or, networking for misanthropic nerds.

I’m shy, awkward around people I don’t know well, and honestly kind of a dork. So how is that I got three of the four jobs I’ve had since college by knowing people? I show up. That’s seriously it. Physically show up to events, make a minimal effort to be friendly, and you will get to know people who will either introduce you to someone who will offer you a job or offer you a job directly.

So let’s get into details. When I say “events” what am I actually talking about? User groups, code camps, meetups, developer get-togethers, conferences, etc. Victoria is not a large city and we still have a wealth of meetups, your city almost certainly has some too. Google is your friend here, as is twitter and other social media. I found out about whiskydev because a friend tweeted about it. At whiskydev I met a friend who introduced me to my new boss, and now I work at an awesome startup.

If you’re particularly shy, I recommend user groups or meetups where someone gives a talk. How do you know the group is having someone give a talk? They’ll usually announce the speaker and topic ahead of time because they’re excited about having an actual speaker (depending on the group’s topic, it can be a huge pain to find someone to speak so organizers are usually pretty stoked about finding someone) and so that people who either don’t care about or love that topic can make plans accordingly. Talks are easier for shy people because a) you can spend most of your time at the meeting quietly taking notes, and b) afterwards you can ask people how they liked the talk instead of agonizing over how to start a conversation. Not that I’ve ever done that.

Another tip for shy people or for people who are really serious about networking is to volunteer. I volunteer with a number of organizations and I speak from experience when I say there is no such thing as too many volunteers. Come early and help set up, stay late and help clean up, or ask the organizers if they need volunteers for anything. The answer will almost certainly be yes, and now you’ll have a defined job to do which makes it way easier to talk to people.

It’s great if you can be friendly and talk to people, but the first step is just physically showing up. Start there and you’ll be fine.

But to be fair, I have to mention that it is possible for showing up to backfire horribly. If you show up and act like an asshole, word will spread. Victoria in particular is a very small town when it comes to tech. The person you’re a jerk to today could easily be friends with the team lead who’ll be interviewing you tomorrow. On the upside, you kind of have to work at it to be enough of a jerk that someone would tell a friend not to hire you. People are generally pretty forgiving and we all know what it’s like to put our foot in our mouths. Just don’t be a dick and you’ll be fine. That doesn’t mean you can’t have opinions, just that you should phrase them as opinions. For example “I hate working with javascript” is just an opinion, but “javascript sucks and only shitty programmers use it” is going to make you look like a jerk.

And one more tip, particularly for students: class counts as networking. Your professors have probably had students before you, and certainly know people in the industry. Those former students may be the ones interviewing you or asking your professor about you. People your former classmates work with might also ask them what you were like as a classmate. Think about what you want them to say before you show up late and blow off assignments. This applies to your current job as well – just like you aren’t going to stay in one place for your entire career, neither are your coworkers. If you interview somewhere a former coworker now works, what are they going to say about you if the interviewer asks them?

To summarize, my tips for networking are:

  1. Show up
    1. Try to be friendly
  2. Don’t be a dick
  3. For extra credit, volunteer

That’s all you need to do to make contacts who might one day help you find a job. “Networking” can sound like something only slimy salesdroids do, but it’s really just showing up and trying to be friendly.

How javascript is like a board game

in development, javascript, opinion

Javascript is much more like a board game than you might think. Let me tell you a story to explain what I mean.

I used to be convinced I just didn’t like board games. I’d played the usual Snakes and Ladders, Sorry, Risk and Monopoly as a kid, and I could happily go without playing any of them ever again. Especially Monopoly. At least the other ones had an end in sight, even in Risk there was the hope of a quick and merciful rout, but Monopoly always seemed to end with people forfeiting just to get the game over with.

Then friends of mine started introducing me to board games that didn’t suck. Games like Clue and Red November and Space Alert and Ticket to Ride. It turns out I like board games after all, I just don’t like shitty board games.

Javascript, as it turns out, is remarkably similar. I used to think javascript just sucked, then I started working with ember. It turns out I don’t hate javascript after all, I just hate shitty javascript. All of the javascript I’d worked with pre-ember was a totally structureless mess – which I freely admit was partially my own fault. The vast majority of my programming experience is in java using frameworks like struts and spring which enforce a lot of structure. Server devs, myself included, don’t always know what to do without a framework enforcing some structure on our code.

Ember is an extremely opinionated framework, which as a veteran of rigid java frameworks I find comforting and familiar :) It also takes quite a few architecture decisions out of the developer’s hands, which is tremendously helpful if you’re a server dev with no interest in reinventing the wheel. Ember certainly isn’t the right choice for every single project, but it works very well in the context I’ve used it in and lets me get my front end tasks done quickly so I can go back to the server side development I prefer.

The moral of the story, in case you haven’t been paying attention, is that before you decide something sucks make sure you’re not just using it wrong.

The most important word a project manager can ever learn

in opinion, project management

There is an amazing, near magical word that can save projects, hit deadlines, prevent burnout, and gain the respect of your team. Sadly, few project managers seem to know it. What’s this magical word? “No.”

Really, it’s that simple. Just saying no (respectfully, in the right situation) can do all of the amazing stuff I listed. It’s not a guarantee of success, but it will give you a fighting chance.

How does “No” save projects? If you don’t commit to more than your team can actually do, your project’s odds of success skyrocket (this isn’t news, is it?). If you say “No” when someone tries to add features without taking other features out or pushing out the deadline, again, that can only be good for your odds of success. If someone tries to change a feature repeatedly, say no until they figure out what they actually want.

How does “No” hit deadlines? If you have too much work for the time you have left, say no to some of it or say no to the deadline. Developers are not magicians, we can’t fit infinite amounts of work into a fixed time period. Say no to some features planned for the next release if you know they aren’t going to fit. Say no if you can only hit the deadline if everything goes perfectly.

How does “No” prevent burnout? One of the biggest causes of burnout is working excessive hours. If you say no to unreasonable deadlines, like magic your team will be able to get everything done on time without living at their desks. They’ll also be happier because they’re being treated like people instead of cogs that can be replaced when they wear out.

How does “No” gain you the respect of your team? Developers actually aren’t idiots. We can tell when you’re sacrificing our time to make yourself look good or because you’re scared to stand up to your boss. We can also tell when you got us the best deal you could in the face of political pressure to manage the project incorrectly, and we will respect you for that.

So if “No” is so awesome, why won’t people say it? Because they want to be nice, because they want to be seen as a go-getter, not a downer, because they’re afraid they’ll never get promoted if they say no, because they’re afraid to stand up to their boss, etc etc. Those are all compelling reasons, but here’s the problem: refusing to say no doesn’t work.

Sure, you look good in the moment, but when it’s time to deliver and the product is buggy or doesn’t have all the features everyone was expecting, you’re in much bigger trouble than you would have been if you had just said no in the first place. If you do that repeatedly, all you get is a reputation for not delivering. If you don’t want people to trust you that’s your call, but you’d better be amazingly charming (or related to the CEO) if you can’t actually get things done.

Just say no to clever code

in development, opinion

I was reading John Sonmetz’s post 11 Rules All Programmers Should Live By and I wanted to expand on 2: Clever is the enemy of clear.

In some cases, you do need to write clever code. If you’re working on something that absolutely must be optimized as much as possible, fine, get clever. If you’re working on something that’s actually hard, like cache invalidation, knock yourself out. But if you’re working on plain old business software like probably 99% of coders out there, knock it off! In almost all cases clever code is just so much mental masturbation: all it accomplishes is making the coder feel good about how very clever they are. Except that writing clever code is actually stupid.

Why? Because the point of writing code is to solve a problem. Clever code, on the other hand, is a problem. Remember, the vast majority of development is maintenance, not greenfield development. It’s much, much more important for other people to be able to understand and modify your code than for you to gain whatever performance or flexibility you think your unmaintainable code is going to get you.

Your job is not to congratulate yourself on how clever you are, it’s to add features so the company can make money, fix bugs so the company can make money, pay down technical debt so that adding features and fixing bugs is easier and the company can make money, automate tedious stuff so humans can do more interesting things that make the company money, etc, etc. And yes, this advice obviously applies to open source as well. At a company, you can make people work on code they hate by paying them. In open source, not so much. If people don’t want that bugfix/new feature badly enough to tolerate the mess you made when you decided to be clever, they’ll remember they could also be doing literally anything else, and then go do that instead. I’ve seen code that made scrubbing the floor sound like a good time in comparison, and if I didn’t have to work on it I most certainly would not have.

Not only that, but clever code doesn’t even make you look clever. Anyone who can see the bigger picture or has ever done any maintenance thinks you’re a jerk and probably a dumb jerk at that. Like Einstein said, “If you can’t explain it simply, you don’t understand it well enough.” If you can’t code it simply, either you don’t understand it well enough or you’re not a good enough designer to make it simple. Do you really want to convince the next people who work on your code that you don’t know what you’re doing?

Clever code actively harms your codebase, slows development, and makes the people who maintain your code want to throw chairs at you. Just say no to clever code.