Are You a Modern Software Engineer?
Are You a Modern Software Engineer?
The path of a software engineer can be represented as a highway. It can have many lanes, and it is up to you to decide how much time and effort to invest in them.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
A global market is filled with vacancies oriented for a particular programming language or some core framework or tool. We are looking for intermediate Java engineers, junior Python engineers, etc. However, is a programming language that important nowadays? A current modern software engineer is far beyond just one programming language or tool. In this post, I will recall basic talent archetypes, explain what makes current software engineering so complex, what non-technical characteristics of a software engineer are also viable for a successful career and/or project delivery, introduce my personal highway metaphor, and urge you to have a look at CVs and job descriptions from a little bit different angle.
As part of my responsibilities, I was involved in a technical interview process inside a software engineering company. I was frequently asked by recruiters and HRs about my view on a technical person from another technical person's perspective. The questions were like these:
- How do you classify technical people?
- What kind of portrait do you create based on CV screening?
- How do you match requirements from a job description to an actual CV?
- What are you looking for other than answers to the traditional low-level technical questions?
As a result, I created a small presentation to recall basic talent archetypes and introduce a personal highway metaphor to describe versatile engineers in low-level details.
A specialist is an expert in a specific area of knowledge.
Specialists are characterized by:
- Deep skills.
- Narrow scope.
- Peer recognition.
- A lot of unknown outside main technical domain.
- System engineer, i.e., Java core development, drivers, any embedded system, etc.
- Performance testing and tuning.
- Proprietary tools, frameworks, and databases, i.e., SAP Hybris, HP Vertica, Hadoop Distributions (Cloudera, MapR, Hortonworks), ETL tools, Pivotal stack, etc.
- Cost more money.
- Are riskier for a company, as they can quickly become bored if there is not enough interesting work for them as they put all eggs in the same basket.
- Harder to hunt and convince to join your company.
- Usually quite specific people.
A generalist is a person with a wide array of knowledge. They're the opposite of a specialist.
Generalists are characterized by:
- Broad scope.
- Shallow skills.
- Quick response in case they possess knowledge and experience to answer.
- Lack of confidence since a depth of knowledge is quite limited.
- Juniors at the start of their career.
- Sales and engagement (purely from an engineering point of view).
- Inexperienced managers.
- Recruiters (purely from an engineering point of view).
"T-shaped" is a metaphor for the depth and breadth that an individual has in their skills.
- Has deep knowledge in at least one area, i.e., programming language, and can be a problem solver in it.
- Understands many other areas and their complexities, i.e., storages, front-end, distributed, big data, etc., and knows how to communicate clearly in that area.
- Possesses boundary crossing competencies.
T-Shaped engineers became popular mostly due to agile principles (focus on self-organizing teams with cross-functional members) since a T-shaped engineer is an ideal candidate to be a cross-functional team member:
Another great argument was that presence of T-shapers would help to avoid a single point of failure (when someone is leaving a project or a company) or appearance of the domain experts, which is considered to be a bad sign for a team.
The thing I personally like most is a clear focus on the boundary crossing competencies, mainly related to the ability to work efficiently in a team. For example:
- Critical thinking.
- Knowledge or processes and engineering practices.
A person who can be a specialist, but is able to change to another role just as easily.
Unlike other archetypes, a versatilist both possesses deep skills and can perform a wide scope of roles.
- True experienced senior engineers.
- Tech leads and architects.
- Delivery managers who came from engineering.
Expert vs. Generalist vs. Versatilist
It is very easy to compare all mentioned archetypes by the depth of skills and the scope of roles and assignments:
A full stack engineer is capable of performing tasks at any level of the technical stack in which they reside. A lot of people tend to forget that full stack is an edge case and each full stack engineer is very dependent on an actual technical stack.
Examples of Stacks
- LAMP, i.e. Linux, Apache, MySQL, PHP
- MEAN,i.e. MongoDB, ExpressJS, AngularJS, NodeJS•
- Microservices, Containerization*, REST, *JS
Full stack engineers:
- Are very stack dependent.
- Can't easily change a stack.
- Are great freelancers.
- Can create turnkey solutions and startups.
A competence matrix can easily show if existing team members are capable of performing any task related to a particular project, what competencies they possess if there are any domain experts or possible single point of failures. The design of the competence matrix can vary, but usually, you have two axes, the first one being for team members and the second one being for all the technologies used in the project. Then, depending on a scale ("no knowledge at all," "can perform a task to some degree or I am an expert in this area," or simply using a scale from one until five), each team member can evaluate themselves. Usually, it is placed in a visible position for each team member to see it.
A competence matrix can help you to find competence gaps, can help you make clever decisions about a possible overlap in vacations for the engineers that are the only experts in particular technology, can help you to make a decision hiring specific experts that are missing in a team, fire an engineer if areas of expertise are backed up by other colleagues, etc.
The highway or freeway metaphor is my personal unification of a specialist, generalist, T-shaped, versatilist, etc. The analogy comes from our adaptive life when it's up to us where to invest effort, time, money, etc. We can invest them in real estate, cars, expensive clothes, or invest more time in career, some courses, and certifications that might help us get a promotion or spend time with family and friends. Our life is a very adaptive process with no right answers for everybody.
Therefore, I started looking at a professional life in a similar way. We have a lot of lanes we might follow. Each lane might have different speed limits, workloads, impediments, and priorities. In addition, we can add more lanes to our freeway or remove some which are not important for us. It is our and only our choice to move forward on each lane by investing the most valuable thing we have in our life: our time.
In my humble opinion, there are a few quite important lanes for a software engineer.
I really like this sort of visualization, as we can easily feel and measure our progress on each of the lanes. In reality, the list can be extended depending on the required level of granularity:
- Technology focus.
- Data formats.
- Search engines.
- Engineering practices.
- Everyday tools.
- Sales skills.
- Presentation skills.
- Communication skills.
Let's look into some of them for a better understanding.
Programming languages can be characterized in different dimensions, i.e., static vs. dynamic, strongly or weakly typed, etc. If you are proficient in one programming language, have a look at others with different characteristics. That might broaden your outlook and help you to have a look at a programming language only as an instrument with its pros and cons.
If you don't want to change your primary programming language, then it makes sense to look at its future releases, get acquainted with new features, enhancements, APIs, etc.
A product can belong to a different domain, for instance:
You can invest your time to better understand a domain you like and currently are working in and, as a result, become a more valuable engineer in that domain. If you are in digital advertising, you might be interested in clicks, impressions, CPI, CPM, CPC, etc. If you are tired of that domain, have a look at any other. This will add a different value to your career and your professional path too, and maybe will help you to find the domain of the most passion to you.
Another lane on our highway is related to architecture and non-functional requirements. One day, you may decide to invest your time into common practices of solving scalability issues of any kind, have a look how high availability is being achieved in some modern and popular products, what helps one solution survive high load, etc. If you are a fan of patterns, then you could have a look at classic patterns first, and then switch to modern ones, recall old school enterprise patterns, or read a book about integration patterns.
If you like the web, then the hype is about monolith vs. SOA vs. microservices, so you can invest time into that area. If you are in a big data world, then and kappa architectures might be interesting to you, too.
Another valuable effort might be to spend time reviewing architectures of successful products.
As another option, a modern engineer can select any of technology focuses and dive deep into related technologies and solutions. The table provided below can give you an idea of what a technology focus can be, but you can add your own option or modify an existing one according to your preference.
Java EE, SOA, ESB, integrations, etc.
Batch/real-time, Hadoop ecosystem, Storm, Heron, Spark.
Scalability, caching, search engines, etc.
Machine learning, NLP, CV, etc.
Smart devices, sensors, etc.
OLAP, ETL, data warehousing, etc.
Virtualization, AWS, OpenStack, CloudFoundry, etc.
Select your technology focus and proceed with it.
Programming Language Specific Technologies
For each platform, there is a particular set of frameworks, libraries, tools, etc. You can invest your time in looking into those. If you are a Java guy, this presentation from Andres Almiray can be a good reference.
If all of your solutions were backed by RDBMS (Postgres, MySQL, Oracle, etc.) then it makes sense to have a look at NoSQL solutions (Cassandra, MongoDB, HBase, Riak, Redis, etc.) or even NewSQL (VoltDB, Gemfire, etc.). This resource can be a great starting point for you.
DevOps and Cadence of Releases
Customers want a software to be shipped more frequently. Continuous integration, continuous delivery, continuous deployment. Have you tried to build a CD pipeline for your pet project? Have you tried containerization via Docker, their orchestration via Kubernetes or Docker Swarm? This stuff is not just for DevOps; this stuff is for us, for software engineers. Play around with it. This can become additional lane of your career freeway.
Think About Your Highway
I can proceed with low-level details, but I hope you got my straightforward idea. Your software engineering path can be represented as a highway. It can have many lanes, and it is up to you to decide how much time and effort to invest in them. When at some point in life you are tired of your career and the way it goes, or you are burdened down, then instead of making any radical decisions (for instance, become a manager or quit your job), maybe it makes sense just to change your focus from one lane to another and succeed in it, too.
P. S. Special thanks to Yarko Filevych for great illustrations.
Opinions expressed by DZone contributors are their own.