A small collection of cases that frequently occur when working in the field of Software.
We are Software Engineers. We pride ourselves to write the most concise code, to create good architectural designs. We tend to believe that our professional life is full of code, debugging, drawings in whiteboards, and software problems to solve.
There are other aspects of working as a developer, however, which usually affect one’s mindset and productivity when working. Whether you are the manager of your company or a developer in a big team, you should not ignore these less technical aspects of the Development’s lifecycle.
Let’s take some time and elaborate on some common cases that have happened to almost all of the developers I know (including me).
The case of idea proposals in a development team
It’s not uncommon for me to become part of discussions where new ideas are thrown to the table faster than they can be processed. That’s awesome, and it should be done regularly. It shows a healthy team and a willingness to participate in collective decisions. It is also an indicator of how good are the relationships between colleagues. If a colleague proposes a radically new idea, it means that this person values your opinion at a level that overcomes the possible discomfort of being rejected — and that’s a good thing.
An example of a new idea would be to follow a new artistic direction inside a computer game, to use a new programming language for specific tasks, or to implement a new feature.
Ideas always come at both a cost and a potential gain. Often, people will reject one because it may bring the team a level of effort that it may become unmanageable before it is fully materialized.
I have been lucky enough to participate in teams where thought-sharing was widespread, but so were rejections. One thing I noticed is that rejections are often done by seniors, leads, or stakeholders (product owners, managers). To me, that makes sense because a high level of familiarity with a project also brings a better view of future software risks. Especially in the case of stakeholders, visibility about time plans, and the dangers of project deviation is much higher than the rest of the team — regardless of the level of communication.
The route of discarding a new idea always has an emotional headstart when compared to the path of taking a new risk, usually because of the following reasons:
- Doesn’t fit with the time plan nicely
- The proposal requires refinement, and often this refinement is eventually being done by the senior devs, who may or may not be willing to risk their productive time to something that may not work in the end.
- The feature may not offer the benefits that it should, considering the effort that would have to be put to it.
But here’s the thing — the proposer almost always has a different view, a complete picture of the proposal in its end state. Since the rest of the team may not be able to grasp the new idea in its entirety, it’s more likely to avoid spending time in trying it.
For these situations, if you are the one suggesting something new, the best thing to do is for you to put yourself in the place of a stakeholder.
If you are a developer, this means that the next time you propose something, suggest to materialize/implement it yourself. Offer yourself to implement it, create a proof of concept. This will not only give you a considerable amount of knowledge but will also earn you higher respect from your peers.
The case of shifting development direction
Smart people (and teams) change their minds
- Jeff Bezos
This applies everywhere — in Software, even more so. There is a reason why, in big projects, there is something called iteration. It means that you had an idea of what you wanted to do and started with path X. Later, you need to scale, and you intend to follow path Y, which will allow you to scale up. This is called “changing your mind”.
The practice of clinging to an idea just for the sake of it has a name, and it’s called “unhealthy fixation”. We live in an industry where mind-shifting is very common. As professional developers, we need to adapt, think new ways of implementing what we want, learn from our mistakes, avoid the pitfalls of the past. As people working in Tech, we need to change our minds, and we need to do it often. As long as we can always justify our choices, of course.
Until I realized this little piece of advice, I was getting annoyed each time that I would have to throw away some of the work previously done, because (as I believed back then) the original specifications were not solid enough. Now, I know that what is going to stick for years to come is not the lines of code I write, but the solution I provide as a whole, and the small joy a feature made by me brought to the users of it. This realization made me change my mind radically as well at some point in my life, and so far, I haven’t regretted it.
Here’s a fun fact: When Steve Jobs presented the iPhone 1.0, it didn’t have any apps or an App Store. It was supposed only to have web apps and expand its ecosystem there. At the time, it seemed like a logical decision, and the media were very fond of the idea of having a web-based platform for web apps in the palms of all people. When the iPhone 2.0 was released, Steve Jobs announced the new App Store, a radical change of direction, providing a platform for 3rd apps to be written in Objective C and published to the end-users.
Imagine how the world would be today if that mind-shift hadn’t occurred.
That doesn’t mean that you shouldn’t pay attention, though. If you believe that you are shifting directions in a way where your team/company/wallet is starting to show signs of burnout, it’s time to stop and rethink what you are doing. You are then not just changing directions, you are chasing your tail, and you may also be suffering from the Leonardo Da Vinci Syndrome.
The case of deciding on a technology to develop with
I believe we (as Software Engineers) can consider ourselves very lucky to have decided to follow a profession revolving around Software in this era.
Never before were there so many diverse technologies to choose from and so many sources of knowledge to be taught by. However, in this glorious era where the science of Software Engineering is thriving, we often find ourselves amid echoes of an “echo chamber” when trying to figure out what technology is appropriate for us. The Internet is filled with articles about how X is better than Y, with big phrases like “the next big thing”, “don’t miss this out…”.
It’s all a windmill or technologies priding themselves to be the best for your use case. However, you should realize that numerically-quantifiable technological metrics (like “performance” metrics, compilation times, etc.), are temporary. Any measurements you see at any given point in time are bound to change as technology progresses. No matter what technology you use now, it’s probably going to be surpassed by something bigger, faster, better, or simpler.
When researching the stack you are going to use, you must have a “decision framework” that’s more likely to stick and apply to your project even if something faster comes along.
In other words, you need to invest in your approach to solving your problems, and not just rely on frameworks. What should differentiate right from wrong appliances are project requirements — not technological trends.
For example, NodeJS being all-async with high performance is not why someone should choose using it. NodeJS has been surpassed by other frameworks for quite some time now in this regard. I usually prefer to work with NodeJS because of its great programming model (middleware logic), its fast iterations, and its enormous ecosystem. However, when it came to deciding on a framework for a team of developers working across the globe, I thought differently. I proposed a piece of technology that heavily relies on a statically-typed language that would facilitate communication through code and future refactorings. I put my personal preference for NodeJS aside and put the priorities of the project/team first. The team then invested time in devising an approach to solving our problems, which would also allow the team to make pivots (even in the language used) without rewriting the project from scratch.
I believe this is the basis of a well-though “Software Engineering” process. Cold, hard math — all choices should be the result of a careful analysis of the requirements at hand. Perform analysis and accompany it with a proper architectural design before you start developing. Otherwise, you may end up with a failing implementation — which will stem not from bad technologies, but bad choices.
The case of the Brilliant Jerk in the office
Working in Tech requires a certain kind of skill and knowledge. It also necessitates the ability to learn, adapt and communicate. Especially in software teams that have undertaken a big project that is going to last more than just a few months, communication and adaptation are essential.
It’s not uncommon in the profession of Software Engineering to come across people that are considered as “Uber-skilled jerks”, or “Aggressive Rock-Star Engineers”.
I have had my fair share of such encounters during my career, and I have witnessed firsthand the negative impact on a team’s performance such a person can have. Managers were too afraid to give them any negative feedback because they didn’t want to lose them. Team members were too scared to confront them because they didn’t want to end up in a fiery argument about the implementation of each task. The biggest loser in this situation is the project.
The solution may seem straightforward — letting those people go. In my opinion, this approach is too simplistic (sometimes amoralistic). Firing a good developer means losing a skilled person with in-depth knowledge of the project, without examining alternatives or the causes of this problematic behavior. If you aren’t sure what is causing this behavior, it’s very likely that you stumble across the same situation in the future, even if that person is moved away from the project.
Most of the time, those high-skilled engineers have a much deeper motivation than satisfying their ego. They usually tend to believe that their hard-earned knowledge is being thrown to the trash when a less experienced engineer questions their methodologies. They may have been working overtime for years to obtain this kind of expertise, rapidly committing pull requests to projects past midnight, to solve one more hard-to-find bug before the deadline. Let alone the implications of a possible inability of these individuals to delegate, which results in constantly being overworked, and always being in a bad mood.
If you are the manager of such engineers, keep in mind that much of the time, situations such as those are solvable, not by laying these people off but by performing the exact contrary. Acknowledge their hard work but do not miss out on the opportunity to give them honest feedback regarding how their actions affect the rest of the team. At the same time, alleviate their burden by assigning some responsibilities to other members. Try to create space for other people to grow. Stress those “problematic” employees to acquire some new skillsets — those of becoming more of a mentor and less than a coder. If this works, you will be creating future Leaders.
“There is no level of technical expertise that can justify breaking a team’s morale”
I feel like I barely scratched the surface of the cases above. There are so many things I could talk about (as I’m sure others have many thoughts, too). Working in the Software Industry is competitive, messy, and at times chaotic. But it’s also beautiful, creative, and rewarding.
The only thing that can guide you through this creative chaos is always to keep an open mind, question everything respectfully, contribute your ideas, and not be afraid to change your ways.