DEV Community: Cole Diffin

Getting to Know Myself

Cole Diffin — Thu, 27 Oct 2022 22:20:45 +0000

I’d like to share some inspiration and something a little different.

I’ve been doing a lot of self awareness and learning about myself lately and trying to understand what I want out of a career/role. I thought I knew. I thought I knew many times. I’ve changed jobs/roles and never found something that quite stuck. I’ve always given my all to any role I undertake, but have never found ‘the one’. A trusted mentor helped me to understand a bit about myself recently (and I didn’t even know at the time that they were mentoring me) Which has led me on a fast track to getting to know myself.

I enjoy development and engineering in general. I enjoy people and culture both building and supporting. I enjoy delivering products and seeing the product evolve. I enjoy making a change in the world, and knowing that I had a hand in even just a tiny amount of something that made someone's day better. I enjoy building things, and not just in the engineering space - in my garden and workshop too! I enjoy teaching, sharing knowledge and finding the right way to do things (even when the right way is not practical or possible) . I've learnt that knowing the right way lets you understand the consequences and tradeoffs for doing it the wrong way. And that it's ok to do it wrong, as long as you understand why. I enjoy the process, both tearing it down and building it back up. I enjoy efficiency and finding the best solution to a problem. I enjoy helping people to both realise and become the best version of themselves. I enjoy researching, designing, finding new tech and evaluating if it is fit for purpose. Helping to establish direction, tech choices, guidance on implementation. I enjoy customer service, supporting the products, hearing and taking on board feedback.
To achieve all these things over the years I've been a Developer/Engineer (at various levels), Tech Leads, Practice Leads, Team Leads. I’ve worked on Frontend, Backend Full-Stack, DevOps SecOps and so many more ‘disciplines’ that people often identify as roles.

But here's the thing; anytime I pick up a role that associates with the ‘engineering’ path the role will evolve towards management. Every time I pickup a role from the management path, it evolves towards the engineering path.

And that leads me nicely into the first key learning that I've come into. A management role does not have to be management. We don’t have to force people into moulds that they don’t fit. It’s not commonplace in NZ from what I have seen, but apparently it’s growing overseas to have Engineering Manager roles where the role is a servant leadership role to the engineering team, and can work as closely with the tech as wanted and needed, but the role is not considered a ‘resource’ towards delivery. I.e. an Engineering Manager can engineer, but does not deliver (in the traditional sense). An engineering manager can use their engineering and technical background to decipher the unknown, to unblock the delivery team(s), or to improve the efficiency of systems. The engineering manager's role is to provide, to facilitate and to allow the team to solve the problems. The Engineering manager should guide, assist facilitate, provide guardrails and direction setting as required, but not actively contribute to the work. This allows the team(s) to grow organically and become empowered to make decisions, and empowered to make mistakes - when a team is given this level of autonomy with the appropriate measures to align that autonomy with the objectives of the business - A truly powerful force will emerge.

I’ve seen and been part of high performing teams. I didn’t understand it at the time, and I didn't understand my contributions and how they were affecting the team. I have tried to replicate the conditions of the high performing team, but at the time, I didn't have the understanding of how my actions were impacting others.

I’ve been lucky enough to trial a Senior Engineering Manager role with my company for a while which has allowed me to experience first hand what feels like a culmination of years of learnings - and I truly believe that this is my path, unfortunately, it’s not a role that my current company are able to keep open. I’ve had a taste now and I am very willing to try and pick up a role somewhere in engineering leadership where I can continue to share my many years of experience to improve shape and build awesome teams and humans!

Now the request part: Do you know of any places that are looking for a collection of talents that can help to shape their engineering team(s) into the best version of themselves?

The ‘job title’ is a super hard distinction to make. In larger companies - it’s possibly something like ‘engineering manager’ in a mid sized company it could be Head of Engineering, In a small company it possibly could be a CTO role. In my research so far, all these roles have similar responsibilities in their own way.

YAWS

Cole Diffin — Wed, 01 Nov 2017 00:50:12 +0000

EDIT: The description dosn't show in the Full View, so the title doesn't make much sense... "Yet Another Webpack Story"

I bet you are here thinking I'm going to tell you how awesome Webpack is. Sorry, you may wish to take this opportunity to find something else to read. Don't worry about it. I won't mind if you don't continue reading my opinion piece. Seriously. It's Ok...

Webpack. It's great right? does everything. It 'Just Works(TM)'?

I've always felt a certain dislike for Webpack - without every truly being able to explain it. I've (finally - after years of avoiding it) used Webpack a couple of times recently and still and not sold on it's "awesomeness".

To start with, Webpack 2 had come out about 2 weeks before I picked it up for the first time. I was aware of this, and figured there would be minor inconsistencies from 1, and that most things would still 'Just work(TM)'. No. Just No. After spending way too long, I discovered that pretty much every plugin created on the internet was now incompatible, and all the tutorials on getting started were out of date. Sometime later, I had a working instance of Webpack 2 with enough plugins and understanding I felt like next time would be better.

Next Time, was not better. I happened to start a spike project with Webpack, and found out that Webpack 3 was now available. I figure why not, surely they learned from there mistakes the first time. And made it an easier transition. No. After spending far longer than I care to admit, I reverted to my previous Webpack 2 config and gave up on 3.

I've had a couple of other dealings with Webpack in various scenarios, but nothing to write home about. It was always on my mind that people rave about Webpack, and I constantly hear how awesome it is. I've kept an open mind on things, but I've never seen nice clear instructions on how to do anything more than basic bundling. (Yes, I know you can do many things with Webpoack, but it ends up a convoluted mess)

Until Today.

I came across some really neat examples of code-splitting and lazy loading, in the Webpack docs of all places. I was pretty amazed - Could Webpack finally be on a winning streak.

I haven't mentioned until now that both at work and personally, I've been using Browserify quite heavily, combined with other tools to achieve the same results as Webpack. I've been open to switching, but as per experiences, have not really seen the benefit of doing so.

After discovering Webpack's code splitting and other fun features, I did a quick search to see how/if Browserify supported anything similar, and came across this: https://gist.github.com/substack/68f8d502be42d5cd4942 a very detailed breakdown and comparison of many Webpack features, and code snippets and more. Reading through that article, my daily wtf/wow rate went up by quite a number. I had no idea that Browserify did all that. I've only been using the basics, and performing some of the more complex actions via other tools, or custom rolled scripts.

I now understand a lot better about why I dislike Webpack, and I'm happy to continue doing so for the perceivable future. But for the present, time to start exploring the Browserify ecosystem again, and see what other advancements have happened in the last couple of years I may be missing out on.

Screaming Snakes in Javascript

Cole Diffin — Tue, 02 May 2017 03:41:26 +0000

SCREAMING_SNAKES case has no place in modern day javascript.

It's ugly, it's vulgar, and it makes any code less desirable to read. I feel like my eyes are being yelled at for doing something wrong when I read it.

The most common place I see SCREAMING_SNAKES, is when someone uses it to define a constant. At the top of a file. Let's think about that for a second. They took the effort to arrange their code in such a way they can put the constant at the top. (let's assume it had positive outcomes and wasn't a pointless re-factor) now, when I open their code, the first thing that hits me in the face is a stack of SCREAMING_SNAKES! They all kind of meld together - typically, I'll just ignore them and move on to where the real code begins. Then at periodic places throughout the code, I get a SCREAMING_SNAKE to the face, which I probably do want to decipher this time, and hopefully, it's named carefully so I can determine the content of the variable based on the name (entirely different rant.)

It's 2017. We have the good(?) fortune to have hundreds of build tools at our disposal to work around browser caveats and implement half baked specs that make embedding SCREAMING_SNAKES completely un-necessary, a.k.a imports!

In my opinion, take your dirt SCREAMING_SNAKES and move them to a separate file. You can even call that file constants.js if that fits in with your file structure. Export all your constants, then you can import them where ever you need to. (and, they will be proper constants i.e. immutable thanks to the transpiler tasks in your build pipeline.) And guess what, you don't need to make them SCREAMING_SNAKE case to make your point.

The history of SCREAMING_SNAKE case in javascript (based on my 1 person poll around the office) is due to the need to identify the constant as a constant, so people didn't accidentally change it. This is no longer an issue, due to the immutable nature mentioned above.