Nobody gives a shit about your C++ skills anymore.
Do you remember the times when computers were difficult to use? Apps as mere grey forms, making your work even more difficult? Software versioned by year, because of the interminable release process ?
In recent years, we have experienced a huge shift in the way people perceive computers. Technology is everywhere, used by everyone.
This mainstream shift of software has created high expectations – it needs to be intuitive, have great usability, reflect real world problems and business processes, and evolve as fast as possible.
It’s interesting to observe how these changes have affected the once invisible software engineers.
The why and what
In order to build great products, they need to be fully understood by the people who build them. It’s not enough to send a list of purely technical tasks to an engineering team and wait for an amazing app to come out.
Getting the big picture of how features work together to help users solve their problems is crucial to creating products that people enjoy. Remember the last time you had to use Outlook? Well, they still don’t get it.
This striving for understanding things has given birth to various techniques that help to analyze the business domain – among others, DDD and Event Storming. These ideas provide ways to connect well-defined technical concepts and the blurry world of constantly changing business.
Watching talks about them at every single programming conference makes it clear that the software development community is well aware of the non-technical skills they need to be true professionals.
Working with people
The fast-paced environment with constantly changing requirements, makes it necessary to reduce communication overhead. Even the most old-school corporations slowly reduce the number of layers between teams that need to work together (the worst I’ve seen so far was where all communication between developers and QAs was required to go through QA managers, even though both teams shared a desk).
A good example of that, is placing the BA role along developers and product people, not between them. When we’re talking about good professional teams, this approach reduces amount of misunderstandings (introduced by the middle layer) and reduces the time required to explain ambiguities.
Another example is when consulting companies place their engineers face-to-face with customers in a bid to make the process of gathering requirements more efficient. I’ve heard a lot of old school programmers freaking out about this (“How do you guys talk to VPs/CEOs? These guys are like gods, it must be so difficult!”), but – with a certain skillset it’s easier than anything else.
The key ability that makes it possible to work with other people efficiently turns out to be empathy. Personally, I find it most important to figure out what the level of technical knowledge the other side has, and, what the thing they most want to hear about is.
It’s really difficult to find a sales person that cares about how R-tree indexes are implemented in PostgreSQL. Saying that you need to make sure that the application performance doesn’t drop when there’s a lot of data in the database is often more than enough to explain a huge estimate on a seemingly easy task.
There’s also another benefit of adjusting the way you communicate with the people you’re talking to – people are more eager to trust people that speak their language, rather than weirdos who talk about things nobody can really see.
Writing software is now easier than ever. Except for very low level programmers, nobody cares about manual memory management and any small inefficiencies in algorithms are easily made up for by the vast amount of computing power which resides in even the smallest device.
However, the modern world introduces a bunch of new challenges, not necessarily connected to what you’re taught on a 5-year long Computer Science course at university.
These challenges are slowly redefining the role of software engineers, making them more cross-functional and focused on the real world.