At the End of the Day, We Are All (Polyglot) Programmers
At the End of the Day, We Are All (Polyglot) Programmers
Regardless of your title, programming is becoming more and more engrained across the industry, and you'll need to know how to do at least some of it.
Join the DZone community and get the full member experience.Join For Free
Let’s forget for a few minutes our roles, our titles, our fancy LinkedIn profiles, and our one-liner twitter tags. I do not exclude myself, who has spent several hours to come up with a catchy and sexy twitter or LinkedIn profile summary
If someone was reading this post 15 years ago, they would probably think ”Are you kidding me? Of course we are all programmers in a software project. What else would you expect?”. And this is absolutely true. For those that have some years of experience, things were pretty simple two decades ago. All development activities were done by people who had studied computer science and called themselves programmers or developers.
But several things have emerged since that era. This post is for everyone who’s working today on a software project as part of a team — co-located or distributed makes no difference at all. No matter what is your role you are programming or you should be programming. As described in Wikipedia, programming, (sometimes called coding) is a process that leads from an original formulation of a computing problem to executable computer programs. One might think: “Okay, I’m a UX designer, I have nothing to do with this crap. Get me out of here”, but be patient for a few moments.
Let’s group the typical team roles in 4-5 generic categories. A software development team usually has the following roles. In several cases one person might wear more than one hat.
- Developers (You can call them engineers, architects, gardeners, or whatever you like )
- Testers (Yeah these people who party when they discover a bug)
- DevOps engineers (I don’t like the term DevOps but I guess you understand what I mean)
- UX Designers
- Manager / Technical Lead (I hope that there is not more than one manager per team!)
Obviously developers are programming. If you are a developer and you are not programming then you are doing something really really wrong or something extraordinary cool. Ideally you should be able to write code in many programming languages. It’s OK to be an expert in one, but it’s expected nowadays to be capable to work in any programming language and understand when it’s better to use one against another one.
Modern testing needs have left behind a long time ago manual testing. If you are still doing (only) manual testing then maybe now it’s the right time to step back and re-think about it. Some years ago I wrote a blog post about the 5 levels of an ideal automated and agile testing. Of course some of the things are now outdated but the main concept still remains the same. Testers should be able to program. They should be able to write automated tests using several frameworks. Even if they only know Selenium, they should be able to write test cases in various programming languages based on the needs of every software system. The should be capable of automating them and apply testing coding best practices by writing maintainable and clean test cases. Other than that testers should be able to read – and understand – code. Reading code written by the developers helps them better understand the system behavior and compare the actual code against the business requirements.
Infrastructure as code. How many times you have heard people discussing about it? It’s a reality even though very few projects deal with it. Today we’ve got all the tools we need (Chef, Puppet, Docker, and AWS CloudFormation just to name a few) to manage our infrastructure as we manage our software code. You can create any kind of environment by a few lines of code and start it or shut it down by a command line utility. You can automatically scale it horizontally or vertically by just writing some configuration scripts. There’s no need to maintain dedicated hardware to host servers, databases etc. Cloud, containers and automation tools are very mature and DevOps guys should be aware of all of them to make the best choice depending on the project needs.
UX Designers. I’m afraid I’m going to make my UX gurus unhappy, but you are expected to program as well. Many of you are probably already doing it – I hope so. A modern UX designer is not limited to produce some assets and mockup design screens. Especially in web projects ( still the majority of current software projects) they are expected to prepare the actual web design by writing CSS and HTML code. Ideally they should be able to use frameworks like bootstrap and work with LESS or SASS to deliver a fully-functional application in terms of usability, navigability etc. Oh yes LESS and SASS are considered programming languages.
At last we’ve got this thing called manager or technical lead. A great manager or technical lead can drive a development to excel and make the real difference on a successful VS failing project. Usually we don’t expect these folks to program or do we? As a manager you should be able to gather metrics and statistics for your development team. This requires you to usually collect data from various systems , ideally in an automated way. You should not expect or ask your developers to do that for you. Most probably they will hate you for that. So it’s up to you to write some code to fetch data from the SCM, your tracking system, your agile board etc. and create a unified report that can give you all the information you need to make decisions. For instance, you should be able to call APIs, write code in Google Sheets, put data in an Elastic instance and make queries etc. I think you get the point here.
Like I told you, at the end of the day we are all programmers, no matter which hat we wear. We need to program to achieve our tasks and assignments. If you are involved in software development projects and you don’t know how to program, maybe it’s time to switch to another job.
Feel free to share your thoughts.
Published at DZone with permission of Patroklos Papapetrou , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.