Doing big things

Fans of Marvel movies know to wait around until the end of the credits to see the extra scene. This adds a bit of time to the theater experience, as the credits go on for quite some time; it takes hundreds of people to make a movie on that scale.

At work, I’m one of a dozen developers on my team and one of several thousand developers in the company. While each team largely sets its own policies, there are some general standards for consistency across the company.

Even relatively small side projects tend to involve several people. I’m currently finishing a small computer science textbook that I’ve been working on for the last few years. Even though I have a PhD, work experience in both writing and editing, and a tendency to do everything myself, my book still has a technical editor, a copy editor, and a graphic designer. I could certainly finish the book without any of those people, but they’ll help me to make it as good as it can be.

In short, any project of significant complexity, even if it’s small enough to be done by one person, will benefit from having multiple sets of eyes. When multiple people are working on the same content, however, it’s important to have standards for consistency and for resolving disagreements. Sometimes this means there’s one person in charge – the director, the lead developer, the author – who makes decisions that the rest of the team will follow. Sometimes it’s a collaborative process. But consistency is key.

What are some things to do to help ensure that your projects are successful?

1. Save frequently and use version control.
Not too long ago, I needed to retrieve some code that had been deleted by another developer who had left the company over a year before. Although the code never made it to production, I was still able to retrieve it from svn, which saved me dozens of hours of work.

1a. Make small commits with good comments.
In the past, my habit was to save when I finished a chunk of development or at the end of the day, whichever came first. That meant that even if a disaster occurred I wouldn’t lose more than a day’s work, but it also meant that my svn commits while working on a project tended to be rather large and contain a number of fixes, making it more difficult to locate a specific change. Now, I generally commit (with a descriptive svn comment) every time I fix one bug or add one new feature. The primary reason for this is so that when I go on to the next change, if I screw it up it’s easy to roll back to the last stable state without losing any of my previous work, but it will also make it easier for any future developer (including future me) to find a specific fix if needed.

1b. Delete commented-out code.
I’m not opposed to comments – I’m in the school that believes that what the code is doing should generally be clear from reading it, but comments are useful to explain why the code is doing what it’s doing and document any assumptions. When working it’s easy to comment out sections of code for testing or because they’re not currently needed, but leaving those in afterwards clutters up the code and makes it more difficult to tell if something should have been turned back on. Version control means not needing to keep commented-out code. Just delete it – it can be restored if it’s needed again in the future.

2. Have consistent standards.
There are a lot of areas where there are multiple ways to do something and it doesn’t really matter which one you pick, but being consistent in your choice makes things easier. For example, my team consistently puts the list of properties for a class at the bottom of that class; while it’s easy enough to use F12 to jump to a given property definition, having all the properties together in the same place in each class makes it easier to look through them when needed, without having to think about it.

3. Use good names.
Few things result in as much unneeded mental effort as deciphering code with unclear or misleading variable names. I’ve certainly had instances where towards the beginning of a decent-sized project I’ve given two properties similar names and by the end I’m having trouble remembering which is which. If it’s not clear what information a variable or property is holding, then the name needs to be updated! Similarly, function names should accurately describe what the function does.

4. Test everything that needs to be tested.
What I’ve struggled with the most as a developer is making sure to test all the things that could possibly go wrong with my code. Unit tests can do a big chunk of the actual testing, but the developer still needs to come up with the test cases. This can be a challenge because as the developer you (hopefully) understand how the code is supposed to work, so you use it correctly. Take the time to figure out all the logic-impaired things your users might do and try those also.

5. Understand the desired outcome.
When I’ve had development that’s gone way over the expected timelines, it’s been because requirements have changed repeatedly over the course of writing the code. While that is sometimes unavoidable, do try to minimize it as much as possible for larger projects by writing a reasonably complete design document and getting buy-in from the relevant people before you start development. Sometimes you even get lucky; I’ve had projects end up becoming much less complex before I ever started coding, because my initial design was more complicated than it needed to be and my design reviewers were able to point out a better way to accomplish the same task. Aside from getting buy-in from key people, a good design helps you be sure that you understand the requirements, which makes it easier to implement them correctly.

It’s always worthwhile to make things easier for the next person who will look at your code. Very often, that person is you.

Thoughts on foster care

I recently gave an “intro to foster care” presentation. What was interesting is that I was trying to both encourage people to consider becoming foster parents, and discourage them from doing so.

Why both? There’s always a shortage of good foster parents – people who really care about the kids and are willing to do whatever it takes to make sure the kids feel safe and have their needs met. At the same time, there are too many foster parents who don’t treat foster kids right. It’s not that they’re necessarily abusing kids, but they’re not willing to put in the effort to become trauma-informed or don’t treat the kids like they’re really members of the family. So I’m trying to increase the number of available foster parents, but only those who are reasonably confident that they can treat foster kids as their own. I emphasize this a lot in my talk – while you have the kids, they’re your kids and deserve to be treated like your kids. If you wouldn’t leave your biological kids out of something, you shouldn’t leave your foster kids out either.

We recently re-opened our home for new placements (we closed after our daughter went home to ensure that we’d be available to support her and her mom as needed), but we’re being pretty selective in who we take because we need to find a kid that we’re the right family for – someone whose needs we can do a good job meeting. It’s not enough to find homes for these kids; they need to be homes where they can be comfortable, where they can feel supported, where they can belong.

Everybody needs a family – whether that be biological relatives, close friends, or otherwise. Are you in a position to be family for someone who needs it?

Finishing

November has been a crazy month for me. Despite the fact that I’ve been out of the state for eight days this month (and, of course, all the craziness surrounding the holidays) I’ve been doing NaNoWriMo.

In NaNoWriMo, National Novel Writer’s Month, you commit to writing a novel during the month of November, where a novel is defined to be a story consisting of at least 50,000 words. You aren’t allowed to start until 12am on Nov 1 and must finish by 11:59pm on Nov 30. I’ve taken a stab at it twice in the past, but have never actually finished. This year, with five evenings left to work, I’m about 14,000 words away from the goal. I fully intend to reach it.

Why keep doing this? As happened the previous two times that I tried participating, my motivation started off strong and quickly waned. But I kept at it, staying pretty close to the required daily average word count up until my travel started. This week, I’ll have to average close to 3,000 words per day (as compared to the 1,667 required if you’re consistent for the entire 30 days). I’m under no illusions that I’m turning out the Great American Novel. Nor do I expect to sell a million copies; indeed, the smarter move would have been to spend the month continuing to revise my computer science textbook, which I actually do hope will sell quite well. There are certainly ways I could have spent all these hours that would result in a much better return on my investment. So why bother? I gain two things by finishing:

1) I’ll have written a novel! Tons of people want to have written a novel, but actually finishing one is quite a bit less common. It’s another item off the bucket list.

2) I’ll have met the goal. 50k words is challenging, arbitrary, and (for those of us who don’t write full time) pretty difficult to get done in a month. Many days this month I haven’t wanted to write at all – in fact, I’m pretty burned out on it right now – but I force myself to sit down at the computer each day (when I’m sure my wife would rather I come upstairs and watch House of Cards) and bang out the words. NaNoWriMo is a commitment, if only to yourself; once you set a goal, will you keep doing whatever it takes until you reach it? Are you a person who gets things done?

Accessibility at Cream City Code

As promised, here are the slides from my Accessibility talk at Cream City Code. Aside from the links (which, if you saw the talk, are probably why you’re here) there’s a fair amount of extra detail in the presentation notes that I didn’t have time for in the talk.

I saw people taking notes during the talk, which is great – this is stuff we need to be implementing! I’d like to particularly thank those people who actually heard me speak on this topic at That Conference last year and decided it was worth their time to come hear me again.

Accessibility slides

Applying leverage

I was reading a finance thread recently where the concept of leverage came up. Simply put, this is asking what activities get you the best “bang for your buck”.

If you’re a minimum wage worker, then activities that save you money are a good use of time because the return is high compared to your hourly rate. If you’re making eight bucks an hour and can save $2 by spending ten minutes making your own lunch, or $10 by spending an hour sorting through coupons, then those activities essentially pay better than working. On the other hand, if you make six figures, those activities aren’t a good use of time (unless you like making your own lunch). In fact, it’s even financially sensible to pay others to do chores you might not enjoy, such as yard work, if it frees up time that you then apply to higher-paying projects.

This applies at the business level as well. If task X takes a senior developer making $100 2 hours and a junior developer making $50k 3 hours, it makes more sense to assign it to the junior developer even though it will take longer. This has two benefits: the total cost of the task is lower, and it frees up the senior developer to work on projects that require his or her expertise.

At a personal level, this also explains why it makes sense to focus on your strengths. Suppose that on a scale of 1-10, I’m at skill level 1 on skill B and skill level 7 on skill C. I’m most likely going to work primarily on projects involving skill C, since that’s what I’m good at. Unless there’s some reason I really need to use skill B, increasing it to level 2 is less useful than increasing my skill C to level 8, which makes me even more valuable for projects that require skill C. (This is a long-winded way of saying that it’s good to specialize)

Would you rather be good at several things, or great at one thing? Would you rather spend an hour saving $10 or making $50? Where does investing your time return the best results?

Thoughts on That Conference 2018

For the last few years, the beginning of August has meant one thing for me: That Conference! The joke eventually starts getting old, but the conference is always worth the time. 2018 was my fourth year attending and second year speaking.

My favorite talks this year were the first two keynotes. When I saw the title of Jessica Kerr’s talk, “the Origin of Opera and the Future of Programming”, I assumed she meant the web browser. No – she actually meant Opera singing! This isn’t a topic that I have any interest in whatsoever…but Jessica’s enthusiasm actually made it interesting (and yes, she did relate it to programming). Then Cory House gave the keynote I was particularly looking forward to, on building a career; he talked about the tradeoffs he had to make to do what he does. Videos of both talks are available on the That Conference Facebook page.

When I’m writing or speaking, I like to choose a topic that’s more conceptual than language X or program Y. Last year my talks were on accessibility (at That Conference) and sorting algorithms (at MKE.NET); this year my talk at That Conference was about graph theory and I’ll be speaking on accessibility again at Cream City Code. Over the last few years I’ve noticed that there are a lot of software developers who don’t have computer science degrees and are interested in seeing what they’ve missed, which is why I’m giving talks on various topics that would normally be covered in the course of a CS degree (and am writing a book in the area as well). I was happy to see quite a few people turn out to hear what was essentially a math talk and stay engaged to the end. Graph theory isn’t something that most of us will use every day, but it definitely has a lot of practical applications in programming.

If you came to my talk, I appreciate it! See you next year for more waterpark and bacon :-)

Graph Theory slides for That Conference 2018

Setting Priorities

Assuming you get to set your own schedule, how do you choose what to work on next?

Do you pick the most important task? The one with the closest deadline? The one most likely to make your boss (or significant other) happy?

After I read about Kanban, I started trying to arrange my tasks such as to minimize the amount of work that I have in progress. My goal is to minimize the number of things that I am responsible for at any point in time.

Obviously, this doesn’t mean that the highest-priority tasks don’t still get done first – I can’t imagine my team leader would be happy if I told him I was going to put off responding to a critical bug report for a week because I have too many low-priority tasks on my plate – but it means that I’ll try to prioritize finishing something that’s already started over starting something new. This results in less time for tasks overall, because you’re more likely to get back to things while they’re still partially cached in your memory, rather than having to get up to speed again before you can start working. I actually prefer to tackle the tasks that can be knocked off quickly before anything else, and get them through the process and off my plate entirely so they’re not taking up any mental energy.

Plus, it sounds a lot better (at least to me) to say “I finished 5 tasks last week and I’m working on my big project” vs just “I spent last week working on my big project.” Particularly when progress on the larger project is difficult to measure, this shows you’re still getting work done.

Communication in Software Development

At a meetup I was at recently, the speaker asked what we thought were the most important soft skills. My answer was English, or more generally, communication.

Programming can be thought of as communicating with the computer – telling the system what we want it to do – but software development is often just as much about communicating with other people.

  • Before we code, we (sometimes) write a design that lays out exactly what the code should do.
  • When coding, we (hopefully) name our methods and variables, and sometimes even comment, in such a manner as to make it clear to the future reader (whether that be ourselves or another programmer) exactly what’s going on.
  • After the code is complete, we may write testing instructions that should be clear as to exactly what behavior is expected from the code.

These are all areas where many people get sloppy. The design doesn’t really explain what the new expected behavior is, the code is difficult to read, the testing instructions are essentially just “make sure it works.” Often much of this documentation fails to be complete sentences. The result is debate over whether or not the code is working correctly, because the stakeholders don’t have a shared understanding of what “working correctly” looks like.

For the QAer, clarity can be even more important: a bug report is much more useful when it specifies exactly what the problem is, what should be happening, and how to reproduce the issue. Specific, actionable bug reports tend to be acted on; vague notes that don’t explain how to reproduce the problem tend to sit in the bug tracking system for years until they eventually get closed as obsolete (or blow up).

Take the time to communicate clearly; it speeds things up in the long run.

Missing indexes in Oracle

Some little details cause trouble entirely disproportionate to their importance. One such thing is a little quirk in how Oracle handles indexes.

I have some code which gets a list of tables using a particular criteria and then gets all of the indexes associated with those tables. Under normal circumstances, the code works fine. However, when testing in a clean database, it will completely fail to find any of the associated indexes, even though they’ve been verified to exist.

…or have they? It turns out that when the corresponding table does not contain any data, the index may still be associated with the table but it doesn’t really exist. So when you run a query like this:

select * from dba_indexes ind
join dba_segments s
on ind.index_name=s.segment_name
where ind.table_name=’MYTABLE’

It returns no results. Cue confusion. Adding a row to the table causes the index to actually be created and allows my script to start working correctly.

Being Matt

When I first started working as a developer over seven years ago, it was a bit overwhelming. Not only had I never worked as a programmer or used any of the languages I’d now need, I also had to get used to a lot of internal tools and processes that often had minimal documentation. It was, in a word, exhausting.

Matt was another developer on the team who had already been with the company for half a year, and he was really good at his job. He wasn’t officially my mentor, but he encouraged me to ask questions. I had him as my code reviewer for my first major piece of development, and let’s just say he had a LOT of comments – everything from functional improvements to changes in variable names. It was frustrating, to say the least – but also educational. Having Matt review my code was a great way to learn what good code should look like, and as time went on I would actively seek to have him as my code reviewer whenever I was working on something particularly complicated; having Matt look at my code gave me more confidence that everything was correct.

Matt recently passed away from cancer; one of my regrets is that I never got to know him socially. We had several shared interests, but I just haven’t made a practice of socializing with my coworkers outside of work. However, his passing leaves me as the senior developer on my team; out of thirteen people I’ve been on the team longest (although one person has been at the company longer) and I’ve been on the team at least 2 1/2 years longer than anyone else who is focused entirely on development (rather than being a team lead). This puts me in the position of often being the person that other developers come to with questions.

I’ve never forgotten how Matt encouraged me to ask questions and assured me that the feeling of being overwhelmed was normal (if I recall correctly, he said it took him about a year to really get settled in). I’m trying to do the same for the newer developers (although, since I’m hard of hearing, I encourage people to email me as it’s more of a challenge when they drop by my office).

No matter how good of a developer you are, there’s a limit to how much code you can produce (although Matt produced quite a lot). By helping your team to work better, though, you can have an effect on far more code than you can personally touch. I like to think that my efforts lead to improved code quality even on parts of the codebase that I never touch myself.

Thanks, Matt. Wish you were (still) here.