As software developers, we’re constantly on outlook how to improve our craft. Readability, maintainability, performance, etc. It is a cause worth pursuing. In an effort to understand what makes code “better”. Or “worse”. Why quotes you may ask. Tell me a project that you worked on, with others, where any aspect of a certain implementation didn’t spark a debate.

Jokes aside (like anyone is laughing), is this bad? Challenging the status quo is a good thing. Especially if empirical evidence is staring at you in a pull request. Either will reassure your current course or you will improve. I worked on enough projects where innovation was met with: We did it like this for the past 20 years and it works. These words should be a trigger for you. Call to action!

Honing your craft and moving forward is your responsibility. It is value added tax on 9-5. Damn, I am starting to sound like those self-help books. I can’t say it any other way. It is extra work. That you’re making for yourself. To be better. If this sounds too hard you can just go along. Spare yourself the trouble. It is just a job. Right?

I opened by saying we’re always on the outlook to improve our craft. Craft is a focal point here. The job is where we trade in our hours for money. Simple. It makes a crucial difference, to me, is how you split these things apart. At work, you will have a title. Senior something or the other. At home, you’re just you. Nothing more, nothing less. No one will pay for your time invested in learning something. There is no ticket on the backlog that says: Learn <insert whatever floats your boat> for no reason. It is just that nagging in your head: Can it be done better? How?

So how this rant relates to changing the status quo at work? Simple. As stated earlier: It is up to you to go that extra mile. There is something that can be done better? Spend that time on it. Ask around if someone else is willing to get things moving. You may be surprised how many people have similar or better ideas. They just accepted the status quo. Build a platform for ideas to surface. Knowledge sharing sessions, brown bags, hackathons. It is not about just you. Spread awareness within the company.

💡 Knowledge-sharing sessions (in whatever form from above you implement them) are a treasure trove. You work with some really smart people. For me, listening to your colleagues on things they are passionate about is, for me, as awarding as visiting a conference. I always end up learning something new. 

After you have a platform where people can share their knowledge, comes a bit harder part. Especially for software engineers/developers/hackers/etc. Being a good salesman. How to sell your idea to all parties involved.

Talking from personal experience, you will need to learn to compromise and negotiate. You may be stubborn, but turns out, so can others. Office politics is a skill you will need to start acquiring. It is becoming more important than learning the latest JS framework. With every new layer in your company, the difficulty level goes exponentially. Would be great if the salary had a similar progression. Sometimes you need to give. At other times stand your ground. Situations differ based on the people you work with. This is something you will learn from trial and error. It helps to have a clear vision in mind. Documented even better.

Different people, different approaches. Don’t take it the wrong way. Everyone has their job to do, so you need to sell your pitch and get everyone on board. You need to be able to quantify why certain refactoring needs to happen over some new feature. It is not another way around. If a team has good cohesion, these things usually require some discussion to get everyone on board. Self-organizing teams, in my experience, can achieve this much easier. Top-to-bottom management adds some layers we need to jump through. This is where the clear vision comes in handy. You will be able to quantify why something that doesn’t add a new feature will make them want to invest valuable time into it. Be prepared to answer any question. Quantify it.

💡 Looking into the number of bugs, incidents, or how much people overestimate when even the smallest thing needs to change. There is always a way to transform technical problems into business metrics. And those will sell your point for you.

To conclude this, let me summarize it in a couple of points:

  • Lead by an example
  • Be willing to go the extra mile in the beginning
  • Build a platform for knowledge sharing
  • Quantify your reasons for the change in business metrics

Hopefully, this gives an idea, from my personal experiences, of how to move forward and away from that status quo. Not a good place to be for a software engineer. Or a company that competes with others on market. So do your best to change it. To improve yourself as an engineer and others around you. Small things add up. One change per sprint can be up to 26 changes in a year. Results will show themselves. They will sell your points without you even pointing them out. And then it will become easier to get other teams moving.

Till next time, lead by example.