I'm a programmer. If you think that means I write code, you're wrong. As a programmer, my job is translating ideas into a working computer solution. Beyond coding, this involves a myriad of tools, processes, and communication.
Translation and coding
Writing source code, or coding, is something I often do but it's just one of the skills I need. It's similar to an accountant entering numbers into a spreadsheet or tax program -- an essential part of their work, but just one of their tools.
The story of how, and why, I produce source code is what defines me as a programmer.
It starts with an idea, from a client, from management, from an end-user, or even from me. I wrangle that fuzzy, grandiose, real world idea into something suitable for our rather limited computers. As that idea mutates and adapts during development, I keep the stakeholders informed about its progress. In negotiations with product managers, designers, and users I represent the computer.
Constraints and stakeholders
I consider all the people I work with to be software developers: the graphic designers, the product managers, the testers, the technical writers, etc. Development is a common company goal that we're all working towards. These people have roles in the process, and it's vital I understand them and can communicate effectively.
To get the right aesthetics, I work with a graphic designer. I must share their vision, and I must convey the constraints to them. Hundreds of little decisions I make will impact the final visuals; the more I understand, the better the result will be.
To get the right features, I work with a product manager. The path from ideal use-cases to implementation can be complicated. Different programmers have different abilities. We're forever bound by time constraints. There are thousands of hardware and cloud options. It's important that the product manager and I stay in sync to ensure we're creating a useful application.
To create a usable product I work with the technical writers and community managers. As much as I tell them how the product works, they relay to me how it's used, and how much sense it makes.
I can't program in a closet. The quality of our final product hinges primarily on our ability to communicate effectively. I think too few people understand this part of our role: a good programmer is a social person.
Responsibilities and engineering
Engineering is where the ideas become a real product. This includes the source code, the scripts, the graphic files and other imported assets. This includes the hardware and cloud setup and configuration, as well as deployment. This includes the final installers and packaged libraries. Bringing all this together is a fundamental responsibility of a programmer.
I'd like to say we've figured this part out, but we haven't yet. We have a huge list of potential tools and an endless number of ways to combine them. It's an ever-evolving puzzle where I regularly find and replace pieces.
Just packaging it all together isn't enough, we have to ensure that it works as intended. Of course, we have to verify all the core functionality, but we also need to meet fuzzy non-functional requirements like security, stability, and performance.
Let us not forget this all needs to be maintainable. Releasing a product is not a one-time affair. As the product evolves, we continually ensure everything is up-to-spec. The team is also changing; our processes need to survive rotation in programmers over the lifespan of the product.
I suppose one could lament the difficulty of this challenge; it can be frustrating and overwhelming at times. But I love the feeling of ever improving. Every project can be done better than the last. I relish in this permanent position of looking for new answers. It brings out the scientist in me!
I am a programmer
My skill as a programmer is measured as the sum of these abilities. While I may specialize on specific projects, I always contribute to the entire spectrum of programming activities. I need to keep up with this fast-moving field. Remaining static would relegate me to becoming a relic of the past.
I take great joy in seeing people use the products I've created. I care about the users and want to make their lives easier. I like being part of a flourishing product and the company that grows around it.
There's no other job nor title I'd rather have.
I'm proud to be a programmer.
Top comments (8)
This is one thing some don't expect when getting in to programming. I know I didn't. I think I might be more on the introvert side than most and I expected that as a developer I'd be sitting in front of my computer 8 hours a day and then go home. But as you say you have to be social if you want to be successful, and I'm working on that. Still don't really like team building exercises, though.
Well, for somewhat depressing motivation, the more sociable programmer will be perceived as the better one, assuming actual skills are at a decent level.
Learn to love everything "team" and the company will grow to find you indispensible.
Unfortunately, know this doesn't make it easier. And bad skills don't always hinder the more sociable ones.
Well said.
Once you solve the problem you only have to write the code.
Programming is about problem solving, not writing code. That's why you should never call yourself a "coder".
I've been paying more attention to my choice of words lately. Separating out "coding" and "programming".
Yes, problem solving, and unfortunately the problem isn't always tehcnical in nature, but deals with human emotions.
Yes! You articulated so well what you (and I) do. Definitely keeping this mind when friends/family/people ask me, "So what do you do again?"
Hell yeah, me too!