Lessons from the software field

A friend posted this prompt on Facebook and I thought I'd repond here.

  • How would you counsel the next generation about your chosen profession? Any regrets? Surprises? Unexpected perks? What do you wish you had known then that you know now?

I'm in the computer software field. My career has been an amalgamation of a software developer and a technical consultant. I love my role, and I'm at the pinnacle of my career because I've been blessed to have the right blend of customer and technical focus that works for me and my family.

It's a broad set of overlapping career choices, so I'll speak to my part as an individual contributor who helps make software as well as talk to customers to integrate ideas and resolve their issues. First, I'd offer some advice about considering this career. Consider software development and related consulting work if:

  • You have some perspective on how things should be done. Or you see that technology doesn't work the way you think it should. The world needs more diversity of thought in this field. For instance, "the data prove(s)" that technology fields need more women.
  • Even if you don't have the big ideas yet, or if you don't feel like you have a unique perspective (although you do...), think about a software career if this is how you want to make a difference. Know that every organization has Information Technology needs, so skills in this area can help you make inroads into non-profit or government work, or working with various other causes that are important to you. It can also make you a lot of money, if that's important to you. Also know that most of these organizations are underserved, and that even basic things like providing new simple data insights or collaboration capability can be completely revolutionary. Allowing people to focus on interesting problems rather than the mundane tasks such as data processing is really satisfying.
  • You like to tinker and have fun making things. Or you like to pick things apart and understand them. There's lots of analysis in this field.
  • You research and bring in others' ideas.
  • You love working by yourself and with little direction.
  • You're able to clearly and effectively communicate your thoughts and ideas, and aren't afraid to speak up when you sense a poor direction.

If you're starting in the field, here's some advice:

  • Learn the basics. Javascript and some other programming language. It's cool to know some buzzwords but if you can't create something interesting from nothing, you'll miss out on a lot of background knowledge will help you diagnose issues. And there will always be issues.
  • Come up with a side project and do it. Anything, really. Just build something. In my teens, I created a running log program that I evolved over years and had hundreds of users. It taught me about customer feedback and deploying updates and deconstructing a large system into smaller bits. Nowadays, this could be a mobile app or a web site or something from the maker movement. Heck, something cool in Minecraft (or older, Second Life) could prove to be valuable time spent.

Some surprises I've run into:

  • Deploying and making software work for customers (which is what pays the bills) is insanely more difficult than writing a novel bit of code or interface in a lab. It's slightly less fun, but in the end it's what matters. You learn by shipping. That isn't to say that you shouldn't create the novel bit of code or interface, but be as considerate of the folks who need to make it work (if it's not you) as the customer using the feature.
  • Nobody can really define roles in this field. In college, I always hoped somebody would tell me what a consultant and software developer do differently. Where the line was between the test team and the development team. What tasks I'd actually be doing. These things are all muddied, although larger companies try to separate it out a bit more. The point is that you have to be passionate about creating interesting and usable products, and not be completely married to only working on the new or exciting front edge efforts. I've seen large test teams, and huge consulting efforts focused on quality delivery, but in the end everyone (including customers, sometimes reluctantly) needs to help validate the system in order to create anything with viability or traction.

I'd consider travel and ongoing training to be unexpected perks. Depending on the role and your preferences, traveling to customers and improving skills are both things that make development consultants more effective, so companies tend to allow and focus on these things. My experience may not be typical, but I had my grad school paid for, and get to travel around the world to set up and deploy my company's technologies. Very cool.

Finally, there are a few things I wish I'd known in my teens and 20's that I have since learned about this field:

  • Much of this work is dependent on personal information management. So, choose some "sticky" tools to organize your notes, snippets of code, and full code solutions. By this I mean devise a system that you can stick with over numerous years. It's quite often that I remember something I did years ago, and wish I had that old code. Of course, NDAs and customer agreements may preclude doing this in some cases. If this is so, seek out solutions within your employer or customer environments. Something simple like a file share, SharePoint site, or common OneNote notebook. Beware that when you leave all of these things will probably be deleted forever, so if you want to pass them on, do it via another means first.
  • Your boss may not fully appreciate you unless you can communicate your value. This is incongruent with the tasks being performed because this is an extraverted (salesman-like) task rather than a deep introverted technical task, so I've found this to be difficult. So, get used to explaining your projects to others. Talk about your approach and your thought process. I wish I had done more of this in college rather than focusing as much on delivered solutions.
  • Using external dependencies you don't understand, or before they are needed, is a really bad idea. I'm a big fan of incorporating other's work for algorithmic things and for aspects of software projects like user interface "widgets" that serve a particular goal. When it comes to some of the more generic tasks required of software development, it can be tempting to keep tacking on more and more libraries and dependencies that fit your needs or to plan for future expansion. If there's an issue, this makes tracking it down much more difficult. If you get into a large or complex system, knowing why your data grid doesn't display the time formatted properly is much harder if you don't understand how the data grid got displayed. Case in point, I worked on a really neat project in college for Microsoft's Imagine Cup competition. It was a web-based code compiler and testing engine. I spent literally weeks of my time implementing a Microsoft library to display a wizard-like interface on the web, and this was distracting from the core features of the platform. The key reason for this delay is that I didn't understand it and when I understood it well enough to use it, I found it was the wrong tool for the job. In retrospect, I should have focused on delivering the simple solution and iterating on it, rather than doing this deep novel library integration.