Tag Archives: programming

career, programming

What I’d tell my younger developer self

I was speaking to a former colleague recently and in talking about my struggle to find opportunities as a coder he asked me if I’d ever thought about becoming a people manager and that he’d always thought I might be good at it. It’s something others have told me as well in recent years but not something I believe suits my strengths or skill sets. But it did get me thinking about if I ever did become a manager, specifically a manager of engineers / programmers / developers, what I’d want to have been told and taught to me at the various stages of my career.

Entry level / junior developer

Don’t be afraid to ask questions because you feel like it might make you look unskilled or like you don’t know something. There’s a lot you’re not expected to know right now and a lot of mistakes you’re unfortunately going to have to experience to learn from rather than being handed that wisdom. And that’s okay. 

Your role is to figure out what problems excite you or that you’re particularly adept at tackling. To learn and explore and share the new technologies, frameworks, ideas, and tools you find with more experienced developers who might have a bit more Life responsibilities that don’t always allow the freedom to do that. Also frankly they might be a little more cynical and jaded and therefore not as open minded as you are. That’s not to say that everything you find is going to be valuable or used. But if you find even one tool or plugin or whatever that saves your colleagues a lot of time and effort not only will you be helping your team but people will notice and that will help your career.

You should also be seeking out mentors. They don’t have to be much more experienced than you. Just someone with similar vibes who you can build rapport with. If you are a white male presenting developer I’d strongly suggest you seek out someone that isn’t the same so that you have exposure to a viewpoint you might otherwise not be granted access to. It will make you a better developer but more importantly a better person. There are also countless examples where homogenous development teams have blind spots. See early iPhone face ID.

Mid level developer

You should be even less afraid to ask questions and many of them should be around gaps you need to fill to get that next level up, which not everyone achieves. You should also be wary of the trap many fall into at this point of overconfidence and its dangerous transition sometimes into being dismissive of others less experienced or non-coders. You don’t know what you don’t know yet and being humble about that will make you a better colleague and help you succeed. Regardless of level there is always someone smarter than you or with a better understanding of certain problems.

You should still be learning and exploring new things, although it’s understandable that it may not be to the amount of earlier in your career. You should be focusing on growing niche skills that excite you and trying to mentor and build up less experienced developers. Growing your code review skills here is both mandatory and immensely beneficial as understanding both what to critique and how to do so based on the individual will be an invaluable skill that also translates to other paths if you decide to branch out of being a developer. It also makes you look more critically at your own code, which will make you a better developer.

You should start the transition from “how do we solve this problem” to “should we be solving this problem” / “what is the real problem we’re trying to solve”. This is often the key unlock for moving from mid level to senior, in my opinion. It’s not easy and you’ll never fully grow out of it, but being able to take a step back and think about things from a higher level is good for your career and personal growth. 

Finally, and this is more subjective and possibly just my opinion, you should make sure you’re starting to have something – hopefully several things – that give you joy and purpose beyond coding. A partner, kids, hobbies, pets, faith, volunteering, community, etc. Career and financial stability are important but they are not the only important thing. Of all the important things career may, arguably, be the least important beyond achieving some financial stability. Also these things help your mental health which makes you a better human and, therefore, a better developer.

Senior Developer

This is where things can really get interesting and frustrating. You’re going to be asked to do a lot more non coding things, mainly meetings. So. Many. Meetings. A good skill here is getting good at saying no and having the courage to do so. To unnecessary meetings or features. But tactfully, not blowing it off outright but thinking about what the real goals may be and suggesting solutions towards those. Could that meeting be once a week instead of three times a week? Could it be something asynchronous like some shared documentation, a slack thread, email, wiki page, whatever?

By now you should have mastered, or be close to mastering, the idea of solving the right problems, not just the ones presented to you. Of identifying the real pain points and fixing those, which sometimes – but don’t always – match up with what you’re asked to build. You should be mentoring and reviewing code more than you’re writing it. Your job is not to write code. Your job is to level up the next generation to their maximum potential. I know, it sucks, you’re at the point in your career where you’re the most adept at quickly solving problems more optimally than you ever have before. But you solving one problem is not as valuable to your team as teaching several others to solve multiple problems better. Be humble, be kind, be patient, and be curious.

Ask your younger colleagues, especially ones near the beginning of their careers what excites them out there. Then dive into it, possibly pairing with them to do so. Pick it apart. Let them show you what they think is cool about it. Show them some of its limitations that they might not have grasped. Don’t destroy their enthusiasm, this is again about teaching – teaching them to think critically about new frameworks, libraries, tools, etc. 

Shower your colleagues with praise, sprinkle them with criticism. In retros, meetings, code reviews, or pairing. If they contribute something cool or find something useful make sure managers know it. Help them in their career. Be the champion you wished you’d had when you were in their shoes. 

Tech Lead

I dabbled at being a tech lead, but I was never really one. So if I’m being honest I’m not entirely sure what it really requires since I could only observe it from the outside. But for the ones I worked with that I liked it was mostly what a Senior Developer would do with the added responsibilities of thinking more broadly around architecture and tooling – with the idea being to make your developer colleagues’ lives more productive but, more importantly, easier. 

Also just sort of acting like a buffer from bad ideas. Sometimes a stakeholder or management will get a “big idea” that you know is going to be a boondoggle. Either from experience seeing something similar tried in the past or just understanding that not all people in charge are there because they’re good leaders. Unfortunately, some are just the loudest in the room or the most adept in corporate politics. You can’t always save the team from these but sometimes you can take on doing a spike to show feasibility – which sometimes leads towards them realizing that it’s not really worth it or not really what they want with a much smaller investment of time and frustration. Sometimes you can draw on past experience where you did something similar, it didn’t work, but you eventually settled on a better solution and using that anecdote to make them pause and, hopefully, rethink.

One thing I will say is if you have someone like that on your team, and I’ve had a few, make sure you let them know how much you appreciate them. Because it’s gotta be exhausting and draining sometimes and knowing that it’s actually helped others makes it easier to suffer. 

career

LinkedIn Skills Match

So I’ve recently been using LinkedIn to apply to jobs a lot. On the job posts, it has this very useful feature that lists the skills that are important to them then how they match up to yours. So you’ll see something along the lines of “this is a good match for you, you match 8 out of 10 skills”.

The problem is that I’ve noticed a lot of the ones that I’m highly matched for are not positions I’d consider myself very qualified for. Now I know your first thought might be, could that be your impostor syndrome talking? While it’s possible, I don’t think it is as some of the skills it was saying I was proficient in were not ones I would consider myself proficient in to any degree. In fact several were ones I had zero proficiency in. So obviously there was something going on somewhere and it got me curious. If for no other reason than the fact that I like to live by “underpromise, overdeliver” rather than the inverse. 

My first assumption was – obviously I had been recommended for skills by others that I don’t have or aren’t confident in my ability and hadn’t noticed. So I looked and the handful that had stood out to me recently weren’t there. Digging into the feature at the bottom of job posts, I found LinkedIn offers an article into how it determines the skills you have and how well you match. There I found my answer. It uses two sets of skills. First the ones listed under your skills section. The second is what they call “implicit skills” which they define as:

Implicit skills: Skills that are extracted from text within any section of your profile, such as the summary, position description, title, and headline. Implicit skills are extra skills that are not directly editable. Any skills on the matched list that were not added by you are considered “implicit skills.” 

I’m not certain if it’s bad descriptions by me or inferences from job titles I’ve had – which the way companies make up and assign job titles is a whole topic on its own that I have some opinions on. But either way, this feels like a code smell. 

I understand the value of automated screening systems. But if it’s making bad inferences, it’s hurting both sides. Candidates seeing jobs that aren’t a good match, and possibly not seeing ones that are because they’re further down the list as a result. Companies potentially getting candidates that don’t really match what they’re looking for, and missing out on ones that do because they’re further down the list.

It’s possible it’s still a me problem. Maybe I just need to rewrite my resume again, making it more succinct and focused. Maybe I need to omit some of my job titles that may have poorly described my talents, but I had no control over.

But to me it still feels like a code smell or possibly even a bug. If nothing else, I feel it’s a problem others might have been feeling but were unclear why. So if this isn’t just me having a “senior moment” and you’ve encountered this issue as well, hopefully this sheds some light on why and possible ways for you to alleviate it.

programming

Impostor Syndrome

Let me start this by saying I’m not writing this for me. One of the blessings of my career at this point was being able to advise and mentor colleagues as they progressed through their own career. Using my experience and privilege to be vulnerable – to share the doubts I still had and mistakes I made so they had space to feel more comfortable about similar feelings they may have been experiencing. It was something I wished I’d had early in my own career.

Recently my position was eliminated. So for only the second time in my career I find myself unemployed. As I’ve slowly begun the process of refining my resume, searching and applying for jobs, and the inevitable string of rejections it’s been – understandably – very humbling. It also has validated those thoughts long in the back of my brain that many developers feel. Developer friends and I had joked about how your career is often an oscillation between moments of bliss where you feel you can conquer any problem and moments of despair where you sit head in hands wondering why anyone trusts you to build anything at all.

Any job search is humbling and demotivating. It’s a lot like dating where it’s 99% rejection (or perhaps I’m just inadvertently revealing how bad I was at dating). Yet you have to have a short memory. Almost like a quarterback who throws a pick six then has to go out in the next series only thinking ahead, never back if they want to succeed.

As someone who is admittedly much more of a specialist I find it especially difficult. Years ago I lamented that it didn’t feel like anyone needed someone with my skills, even though I found myself hired over and over again for exactly those same skills. Reading job descriptions today I find those same feelings rising up. My JavaScript skills have definitely progressed a great deal since when I originally wrote that. But still when I see UX Developer positions asking you to be an expert in React (or Vue or Angular or etc) I feel those doubts rising again. Yes, I’ve built React components and written a lot of React, jQuery, CoffeeScript, and even just plain old vanilla JavaScript. But I would never consider myself an expert and have never felt really confident in my skills there. I’ve always felt like a hacker – piecing solutions together by looking at examples or Stack Overflow posts and adjusting it to what I need. Much more a MacGyver than a NASA engineer.

Sometimes, late at night like when I write this, I wonder if those feelings of impostor syndrome are getting validated. That I really was a fraud all those years despite all the contributions I’ve made to numerous companies / repos and the recommendations I get on LinkedIn. Why would anyone hire me when there are so many more talented developers out there?

While it’s true I’ll never be one of those “10x programmers” I still think I can provide value to a team. I believe I have strong communication and empathy skills, the data combating my doubts. I know how to write accessible, responsive, semantic, and modular components which are necessary and valuable – even if I might struggle to manage state or pull from an API. I’ve been told I’m good at discerning what the real problem we seem to be trying to solve, rather than just building the solution asked for – which can often save frustration and valuable time. Or as a friend recently told me when I talked about my doubts “You can do a lot of meaningful work.” – which is kind and gracious of them to say, even if the more cynical part of my mind wryly thinks it’s something you might tell Grandpa so he’ll behave and stop annoying people.

I don’t think this will be an easy search. Going through my network there’s a lot of very talented people who are either also laid off or in threat of it. But I’m hoping both that someone gives me a chance and that I validate that show of faith. So I can still have my impostor syndrome, but with health insurance and a paycheck. 

Again, all that to say if I can feel this insecure and doubtful about my future with all the data accumulated telling me I’m wrong – if you’re at a very different point in your career and feel the same, those feelings are valid. Not that they’re right, just that it’s ok to feel them. But we still have to just keep swimming.

programming

The problems I’m excited to solve

I’ve recently been told that as someone who has passed 40, I should not talk about my age because that may hurt future chances of employment. I disagree with this for two reasons. 

One, ageism is one of the many “isms” people face in employment. It’s also one that seems to get less sympathy which is fair – with age usually comes resources, power, etc that cause this to be far, far less of a challenge than sexism or racism. And I am not trying to dispute or change that assumption. But I am someone with a lot of privilege, so I think I have an obligation to use that to talk about it since I can assume more risk.

Two, I think aging is a benefit. I am far more kind, empathetic, thoughtful than I was in my 20s and even 30s. I’ve suffered loss and experienced deep grief. I’ve not had my own children but I’ve helped in the raising of my niece and nephew as well as trying to be a good role model and source of advice for my younger cousins, of which I have many. I’ve gained a lot of perspective and patience that I didn’t have early in my career. I think that’s led me to be a better person and colleague, hopefully.

All that to say as I’m about to turn 45 in a few months and I reflect back on a programming career that, depending on whether you count personally or professionally is somewhere between 18-25 years, I’ve been thinking about what problems still excite me to solve. What kinds of opportunities or challenges still are processing in the deep recesses of my mind even as I’ve gotten better about shutting off once I step away from my keyboard. Because, like most programmers, even if I’m not actively thinking about some technical problems my mind is often running them on a thread somewhere.

At my current job at MassMutual I’ve worked on several teams, often concurrently. I worked on the relaunch team for the anniversary when I started, helping to build a new brand and site. On a “robo advisor” team, offering financial advice to our customers. On the authentication team handling login and signup. On the calculators team offering a suite of tools to determine how much of different types of protection our customers might need. Finally on a team that builds a tool that allows advisors to service their book of business and customers, handling common transactions, and providing policy details. Also a few other teams here or there to help and, again, I was often working on two or more of these teams concurrently.

With the exception of all but the first these are what I’d refer to as application teams – ones building a specific application for a purpose. But for the last several years, since before even the pandemic I believe I’ve honestly lost track, I’ve also worked on our design library team. Building what one of my colleagues described as “Blueprint Design System is MassMutual’s design system that includes reusable styles and components that are consistent, accessible, and responsive”.

Aside, this got further confusing as there already was a blueprint CSS framework which only I was aware of and hadn’t been updated in around a decade when I brought it up, again showing my age. Also MassMutual later acquired a company with Blueprint in the name adding internal confusion at times.

My point is that this last team has been one of the great joys of my career for multiple reasons. 

First, on most previous teams I’d worked with I’d been the sole “UX Developer” type. Which is to say I was the one that did most, if not all, of the HTML and CSS / SASS development usually with only cursory review by the rest of my team. This was the first time I could actually both give and receive constructive criticism from other developers that had an interest and skill set very similar to mine. As a result my skills in both writing and evaluating code grew immensely. And I learned a great deal about what I should comment on and the tone it should carry, through a lot of mistakes.

Second, the team was a mix of developers and designers working together to provide patterns in Figma, HTML / CSS, and React depending on the user’s need. Which is to say if someone was a designer they could use Figma components to build designs for the applications they worked with. If someone was a developer and used React they could use our React components and if they used some other JavaScript library they could use our CSS file and HTML patterns to build their own components. But to my first note here being able to collaborate with people in design was very rewarding as it caused me to rethink problems and challenged many assumptions I had, causing me to grow to be less rigid as it was less of design “throwing something over the wall” and more of a collective effort. We both grew more invested in each other’s success by this partnership. Plus I was fortunate to work on a team just loaded with lovely and talented people, which is always a bonus.

Third, approaching problems from a library versus an application perspective causes you to think differently about solutions. It goes back to that description from my colleague – reusable and consistent. How do you make something that is useful to teams – managing that slider between specific and generic? How do you offer some variants while also constraining them so it’s not just a soup of helper classes and multiple components that all solve similar problems only slightly differently so that it’s confusing what teams should use and the product cohesion suffers? Because, again, the goal is to provide a library in which multiple teams are using so that the site looks more like it’s built by one team instead of dozens each building small sections of it.

We built this on top of the bootstrap library, something which several jobs and multiple freelance gigs I’ve worked with have used so I had a ton of familiarity with. I’d also grown to understand its problems – by trying to be everything to everyone it suffers. Internally we took several measures to limit this like not including almost all of the utilities and helpers but also being mindful of the examples we used – trying to limit the variants we talked about in our internal documentation even if someone familiar with the underlying framework could understand more options might be available, although potentially not branded.

This also gave us some unique challenges with branding and cohesion. Often we would want something to look a certain way, say like an H2, but we would not know where in the code it may appear semantically. In the bootstrap model you’d use some helper classes. But where we had so many consumers we wanted to make it simple if something changed – like if a card header suddenly went from looking like an H2 to an H3 – so they’d have minimal code changes beyond ticking up the version, if we could help it. One of my colleagues started playing with SASS placeholders and it’s something we ended up using extensively.

This would allow us to build a bunch of typographic styles and instead of having them assign a class we’d use a placeholder so we could do something like .card .title { @extend %h2; }, moving the helper classes from the HTML to the SASS basically. Which means if later on it should be %h3 or %h4 we’d simply change the SASS, tick up the version, and they’d update – no further code changes.

Maybe this is a simple thing and everyone is doing it. I know in the bootstrap SASS they do something similar, though often through mixins instead. But it just was something I found exciting and powerful, enabling me to solve problems in a much cleaner way. And that was many of the things I found on this team – when I had to think about how to build a library to help other people, what concessions and trade offs did I have to make in order to make their lives as easy as possible? That was interesting and kindled my passion for my craft and work.

I think the library has brought a lot of value. Many of the teams at MassMutual use it, meaning they don’t have to write their own CSS, patterns, or components – saving them untold amounts of time. The company benefits as it’s more consistent in design and branding, as well as being responsive and accessible since that’s built into the library components. And those of us working on it enjoy working with each other to solve problems as well as the reward of hearing feedback from other developers who benefitted.

So to answer my original question – these are the types of problems I’m excited to solve. Using my skills and experience to provide library components that save my colleagues time and effort while also providing the company I work for with multiple types of value. Finding unique and interesting ways to solve those problems and manage the tradeoffs that are inherent in anything we do. Using my skills and talents to help people in whatever way I can, even if it might not change the world.

I hope I can continue to be blessed with opportunities to solve problems like this for however long the rest of my career is.

programming

Hiring a Senior Developer

A few years ago I took part in a working group for a large company I was working for. In a highly competitive market, especially at the time, identifying senior developers – specifically talented ones – was a big problem. Even more so for a company that while profitable and stable wasn’t exactly the first one developers thought of.

There are many common ways to evaluate a developer. Often coding exercises are employed but those are more often for people just starting out so you can evaluate that they have the basic skills for the position. Puzzles, like the ones Google has used, can help to discern how someone thinks about and approaches a problem – “how many X can you fit in Y” for example. 

My argument at the time was that if you’re trying to find a senior developer, maybe this wasn’t the right path. While it is possible to have say 8+ years of experience and still not be a very good developer, I didn’t think a coding exercise was going to help us here. Especially if you’re looking for a strong, skilled developer. There was a real risk that if we asked too much of them or bored them, they’d walk away because they had so many options. So how do you balance that trade off – not pushing away desirable candidates but finding out enough to feel confident in your hiring decision?

So we started with the question: what are we really looking for when we say a senior developer? For example imagine you have 3 levels – beginning, intermediate, and advanced then how do you define when someone crosses over from one to the next? While years of experience is important, it’s not the best metric. I’ve met developers with 2 years of experience that I trust much more than some with 20 years of experience. So we started to tease out what we really meant and came up with several metrics.

  1. Experience. While it’s not the most important, it is important. Mainly in that over time you see different ways to solve problems, more importantly the wrong ways to solve them. You learn from mistakes, not successes. Often one thing that makes me trust a developer more is when they are presented with a problem their first instinct is not “how do I solve this?” but “should I solve this / what is the real problem we’re trying to solve?”. 
  2. Identifying complexity. This is important in grooming to make sure you have tickets that are of reasonable size. But also in understanding that everything is a trade off – so are we making the best one available? It’s also spotting those things that seem simple at first glance, until you start to pick them apart. Something that builds trust with me is when someone asks probing questions that cause others to think beyond the surface and go something like “oh, that’s interesting, yeah what about X? Or what do you expect when Y happens?”
  3. Communication. Think Reddit’s “explain it like I’m 5”. Can they break down complex, technical problems and solutions into something digestible to non-technical folks? Can they ask the right questions to make sure we both understand and actually address the problem? Can they tease out expectations? Can they mentor and level up other developers through pairing and code review – guiding them to solutions and not solving it for them?
  4. Technical review. Can they help non-technical people list out technical requirements for tickets? Can they understand dependencies on other libraries or teams? Can they spike on a new library, plugin, etc to understand the solutions and drawbacks it offers?
  5. Humility. Can they take accountability when they make a mistake or bug? Can they show grace to others when they do the same? Can they keep their ego in check – like using a library that does most of what we want instead of just immediately writing a new one themselves? Can they solve only the problem at hand, not future problems we may never get to and which will only add complexity to the code base?

With all that in mind one of my favorite suggestions was that instead of presenting a candidate with a coding exercise we give them code to review instead. This would allow us to see what they focus on and ignore. Whether they identify problems we expect, or ones we didn’t think about. Give us an idea of the tone and how constructive the feedback they might provide is. It’s more like an essay question instead of a multiple choice. As I said before, can they guide instead of tell? 

An article I read that stuck with me talked about something along the lines of “it’s not about making every review be an A+, it’s about improvement. Making a B into a B+, making a C into a B. Etc.” That really struck me as someone who can be a bit of a perfectionist and have unreasonable expectations of myself – it’s important to not push that on others, only to help, to teach, to foster learning, and most of all to be kind.

We’ll always find ways to improve on the code past us wrote as one of my favorite webcomics lays out expertly. “Perfect is the enemy of good” after all.

Finally, on hiring in general I saw something interesting on Hubspot that they do some version of near the bottom of most of the developer positions I saw there. “We know the confidence gap and imposter syndrome can get in the way of meeting spectacular candidates, so please don’t hesitate to apply — we’d love to hear from you.” with links to articles about what they mean by “confidence gap” and “impostor syndrome”. But I thought that was a really interesting way not to drive away quality candidates and be inclusive.