paint-brush
Make Engineering Great Againby@gossipprotocol
176 reads

Make Engineering Great Again

by Gossip ProtocolJune 27th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>by Ratnadeep Abrol</em>

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Make Engineering Great Again
Gossip Protocol HackerNoon profile picture

by Ratnadeep Abrol

So, I wake up at 1.30am (look, I’ve got kids that get up at 6:30am, I go to bed early these days… please don’t revoke my developer credentials…). Anyway, I wake in the middle of the night, remembering an interaction at work that’s pretty standard in developer circles, but rarely ends well:

I was working on the interface between two business functions; lets say costomer servos (CS) and fonance (F) (names have been obfuscated to protect the innocent). Here, there was a concept in CS that also existed in F, but the CS definition was not one with which F agreed. Even though this was the case, the respective functions currently worked and interacted with each other. So, no harm no foul.

But my team’s job is to automate this interface and, as developers know, you can only provide an automated interface when you are able to translate between the interfacing parties; whether that translation is pass-through or something more complex. In turn this means we, the developers, need to be the bridge over such dragon infested waters.

We’ve all been there. And, as the adventurer who’s stumbled across these uncharted seas, the realisation dawns that you need to challenge the preconceptions of two separate entities. And, with that realisation a knot develops in the stomach…

How did this little digestive-function-compromising scenario resolve it self? We (the devs) pointed out the problem; the decision makers in each of the functions involved got together with us; we all discussed; we all swapped competing ideas; we all got confused; and eventually we all came to a shared understanding of the problem and then to a solution that everyone was happy with. I’m paraphrasing for brevity, but the point is all this happened in the space of one calendar working day, and on the day the problem was identified.

So why was this enough to wake me up? Well, because it’s a pretty great way to solve a problem: collective responsibility and ownership, open sharing of ideas and safe challenging of opinion. Again, why was this the deal breaker on whether or not I needed sleep? Sadly, it was because I know that for a majority of developers this isn’t something they’ve ever come across.

Having been working in software for a while, I’ve been able to experience the good and the bad that comes with this job, and from my experience it seems that the good behaviours described above are only on offer in a few organisations; most notably some small companies, and enclaves within large organisations.

This was such a productive way to solve a task: everybody learnt and everybody was happy with the resolution. Obviously it’s not always like this — there will be exceptions — but it’s the norm for me in my current working environment. Why isn’t this the norm across the industry?

There are many competing theories to answer this question, and many methodologies that will tell you they solve the problems inherent in solving problems across departments that reason differently, that function differently and have different core values. I believe there isn’t a one-size-fits-all solution, and so much depends on the people and culture you’re immersed in. If you long for an environment where engagement and open cooperation is the norm rather than the exception, then try and change your environment (easy to say, hard to do, but you never know if you don’t try). If that doesn’t work, find an environment in which this is the case and join those like minded and driven people. Those of us that have the ability and opportunity to do so (and I realise not all of us do) have a duty to make our industry better.

Ask yourself how you can do that, and when you’re going to start.

About the Author

I’ve been in the software industry for more than 20 years working in various languages and domains: C, C++, Java, and now Python; Retail, Finance, Law Enforcement Training/Asset Management, and now Vacation Rentals. I class myself as a life-long learner and am revelling in my current journey into Python and AWS. Whilst software is my passion, I understand that passion can only be fully realised within an organisational culture that supports that it. That knowledge makes me an advocate for organisations knowing and exhibiting their culture in everything they do.