I was doing a question-and-answer one time at a university’s ACM (Association for Computing Machinery) club. This was a bunch of 18-22-year-old computer science majors. There were a couple of interesting technical questions but the overriding theme was about employment and careers. The main question was basically, “How do I get a job?” My answer was this:

You have to know something other than just how to code. Don’t get me wrong, coding and the art of software engineering is key. But there’s a relatively small amount of jobs in the world that are just pure computer science and software. Most software written in the world solves some business problem, so you need to know both software development and something else. Software and health care. Software and finance. Software and automotive engineering. That’s what will make you valuable to an organization, is if you know how to use software to solve the problems in their domain.

If you have any interest at all in software development as a vocation or career, it has seldom been a better time. Nearly every industry or company has software somewhere in its competencies, whether it’s developing web-based apps for product management, backoffice application development to support accounting and sales, or even just scripts to automate tasks for yourself.

In fact, it’s even more interesting than that. I believe that: Any job (almost), can be improved with judicious use of software.

If you do a job, I can probably spend a few minutes talking with you about it and excitedly come up with several software ideas to help you do your job better and faster. Now imagine if you had the tools and training to do it yourself. What if you think about your job, not as a “turn-the-crank” mentality of getting some task done, but thinking about the process, the automation, the quality control, and the streamlining of getting that task done?

There’s a really good book that covers this idea in more detail: The E-Myth (https://www.goodreads.com/book/show/81948.The_E_Myth_Revisited). This book shows a great example, an entrepreneur who owns a pie shop. What’s the primary goal that this business owner should have? Is it baking pies every day? Or is it building a company and a system that makes pies of high-quality and as efficiently as possible?

If you’re a technologist, then it behooves you to know a little bit about the business you are supporting, the industry you are involved in. For example, what are the strategic priorities for the organization that you support? What is your industry’s tolerance for errors? What are common problems or challenges that the business tasks usually face? Are the users of your software generally well-trained in the software, or is this for people who haven’t had training? Will your software be used on a table? A phone? Outside? In the dark? Under stress?

Some of this can be figured out with really good requirements gathering and end-user interaction. But sometimes you need your own knowledge about the environment you are working in. If you have to take every single little issue to the users then it can greatly slow down your progress. And anyway, if it’s “should this button be green or blue” type decisions then you probably won’t get consensus from users anyways. You just need to use your best judgment to make a decision, but if you don’t know anything about the context then that decision is a lot harder to make.