Show up

This is a guest post from Elise Shaffer. Enjoy.

Dear New Developers,

As I sit down to write this letter, I’m struck by the thought that I don’t know you. You could be like me, a person who’s loved computers since she was nine years old and has taken every opportunity to learn more about them. You could also be one of the many people who’ve recently graduated a coding bootcamp after spending years in another career. You might have an experience somewhere in between or vastly outside the two.

So, the challenge put to me is to give advice about starting out in development that would be applicable to you given the wide range experiences that might have brought you here. Thinking about that led me to a revelation that the best advice I could give is to show up.

Software is about human relationships. I know this is a point that’s appeared on this blog before. I won’t rehash all the reasons that’s true, but I will use it as a starting point to say that it’s important to have people with diverse experience designing software. It’s important that no matter where you are coming from that you show up. Bring your experiences, struggles, values, and tastes to your work as a developer.

You’re starting out and will probably feel that you need to catch up to your peers. Certainly, there is always more to learn in software development. But you also have so much to teach those around you. Maybe you have an aunt who needs assistive technologies to use the web. Maybe a computing error caused trouble in your previous career. It’s easy to get lost in everything you don’t know. But, it’s just as important to draw on your previous experiences. For example, maybe you used to work in manufacturing safety systems. Safety is incredibly important in manufacturing and it’s also important in software. Or, you might have taken foreign language and culture electives in college that help you understand how design decisions will be received internationally. How can those experiences help you work on projects with your team?

Don’t be afraid to ask stupid questions. It might seem like a stupid question to you, but it’s more likely that what you’re asking is something the rest of your team takes for granted.

Software should support people. In order to do that it has to understand people and the only way to ensure that, is for those designing it to draw upon the biggest well of experiences possible.

There is always more to learn about programming. But, you already know so much that you don’t even realize. Bring that knowledge and experience to your work as a developer.

Best,

Elise

Elise has been fascinated with computers since she was a child. She’s worked in the field for ten years across a few industries and now works as a Senior Software Engineer at Red Canary. She also blogs at eliseshaffer.com.

Software is about people, not code

Dear new developer,

When I was starting out, I thought that software development was all about code. After all, that was the main thing I was working on. Well, maybe not the main thing, as I needed to know what code to write, how to interface with other code, what was the problem being solved, how to deliver it, the correctness of the code, and how it could be maintained.

But, the writing the code felt like the most important part of the job. It was certainly the most tangible and fundamental. After all, if the code doesn’t work, all those other things won’t matter, right?

This led me to focus on how to write code. I wrote up a style guide for the company. Researched new technologies. Read and commented in online forums. Learned how to decompile java bytecode to reverse engineer proprietary software. Argued about code formatting. Joined a design patterns discussion group. Attended meetups and blogged.

I undertook all of these activities to be better at writing code.

However, I eventually learned that people were far more important for the success of a software project than code. This crystallized for me after I saw a few very interesting (to me!) codebases abandoned for lack of a market or other business flaws.

This was a surprise to me, insofar as I’d assumed the code was the most important part of software development. But really:

  • Software and code is created for people and their purposes. It doesn’t exist on its own, isolated from human needs.
  • People will use the tools or applications built with code (or, worse, they won’t). This means that they have to be bought in to what is being built and consulted about functionality.
  • Most people don’t know or care about the code. (If they did, they’d likely be a developer.) They’re just trying to get something done. The most beautiful, well tested, flexible, configurable, documented, future proofed codebase that does the wrong thing is useless.

At the end of the day, code is a general purpose tool, just like accounting or research and development. Code must solve real world problems of real people.

Sincerely,

Dan