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 of 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”

Conclusion

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.