DEV Community: Kevan Carstensen

The background magic of present-day software development

Kevan Carstensen — Mon, 16 Nov 2020 00:17:28 +0000

One of my projects at work over the past couple weeks has been deploying a local copy of some sampling software to prepare for our holiday volume. This is a lot closer to ops than I usually get, and was a fun reminder of how far ops processes and tooling have come since I started my career. Here's what I had to do:

Write a Dockerfile for the application that builds a runnable container.
Edit a YAML configuration (the specific schema is maintained by our DevOps team) to specify CPU, memory, repository location, and some other things. This is translated into appropriate Cloudformation files by some of the DevOps team's software.
Use a Slack command to deploy the application.
Application is ready to use, complete with basic graphs/dashboards.

In a happy path case, this takes an hour or two and is self-service, in the sense that a developer can do everything without any work from the DevOps team. I can use whatever language or tech stack strikes my fancy; it just has to eventually build into a Docker container. ¹

Compare this to the process (such as it was) at my first "real" job, as a system administrator in higher education ²:

Developers talk to the sysadmin team about the software: its tech stack, availability requirements, customers, etc.
Sysadmin team identifies the appropriate server or servers to host the application, possibly provisioning new servers as needed.
Sysadmin team installs appropriate dependencies for the software, establishes a baseline working configuration for it, commits the result to a Puppet or Cfengine config so it can be reproduced.
Sysadmin team typically works with developers on tuning, monitoring, etc.
Application is eventually ready to use.

This process might have taken some weeks in a common case, and was most definitely not self-service. The difference between this and my current organization is pretty stark, and that's across about a decade; not all that much time.

There are other examples that fade into the background. While I might fault my editor for taking up too many cores or too much memory, I can't fault its ability to apply static analysis to my code and flag issues (typos in variable names, rubocop offenses, etc) immediately after I create them. The observability tool supported by the sampling software I'm deploying gives me the ability to quickly answer arbitrary what-if questions across billions of data points generated by our application. So on and so forth.

Whenever I get frustrated by the software industry or the day to day as a software engineer, I try to remember these examples.

What parts of modern software development would have seemed magical to you at the start of your career? Is there a framework, a mindset, or some other thing that makes you happy whenever you think about it?

There are many criticisms, good and bad, of containerization, but being able to do this is pretty cool when you think about the alternative. ↩
This is back when system administrator was a job that one might find in a variety of places. Modern, widespread DevOps (and associated patterns) didn't exist. The term itself did exist, but served more as an umbrella for various discussion groups, IRC channels and small conferences than a widely known set of practices. ↩

Longevity in software engineering

Kevan Carstensen — Mon, 02 Nov 2020 01:35:37 +0000

Software trends young ¹. Many software companies are pretty young, as, arguably, is the appeal of CS to a broader group of students. It seems natural for the age of the typical tech worker to be younger than it is in other professions because of this. It's also true that tech has consistently faced charges of ageism. One doesn't have to look far on the internet for examples of explicit or implicit ageism (Blind, Quora threads as examples).

I'm comfortably into my 30s. I've been fortunate to have a rewarding career so far, and I have a long list of things I'd still like to do. I hope for another couple decades to chip away at that list. That said, my own personal experience – seeing how hard it can be for friends my age and older to get their next job, hearing subtle ageism in interview roundups ² – gives me pause.

I'm working on a couple of longer posts about the arc of a tech career and, in particular, how age bias affects that. For now, I wanted to put up this discussion post. Is this something you're worried about? Do you think it's overblown? Do you do anything to help guard against it personally? Do you see a future for yourself in this field in 15 or 20 years?

See, e.g., this chart. These figures – or similar figures – were widely reported in the media, though it's not clear from that site where the data came from or how reliable they might be. Compare that to BLS statistics showing the median age of the workforce as a whole – early 40s. ↩
"I don't get the feeling that he's a lifelong learner", "she hasn't had a consistent title progression over her [25 year] career [in which, because of title inflation, she may have topped out at sr/staff/etc 10+ years ago]", etc. ↩

Remote work: here to stay?

Kevan Carstensen — Mon, 26 Oct 2020 03:37:09 +0000

Like many developers in the US, I've been working remotely since March of this year. It was hard at first – losing the social connection and routine of the office was a blow considering everything else going on this year. I've gotten used to it, though.

Many prominent companies (Facebook, Twitter, Microsoft, Shopify, Dropbox, etc) have committed to have remote work as an option even after the pandemic. Anecdotally, the majority of recruiter emails I get these days are remote positions – not just pandemic remote, remote period. These are for startups; rarely for big tech companies.

My question, seeing all of this, is whether this shift towards remote work lasts beyond the pandemic. Do you think the companies that have embraced remote work will one day reverse themselves, like Yahoo back in the day? Or is this trend here to stay? Would you want to work mostly or entirely remotely? Would your lifestyle change if you could?

But what about passion?

Kevan Carstensen — Sun, 18 Oct 2020 23:30:17 +0000

I like reading through my old CS coursework every so often. It's fun to reminisce, and it's in a way validating to see how far I've come since then. It's also a little bittersweet.

During school, I was passionate about the field. I read research, I had side projects and open source contributions, I learned (and was genuinely excited by) new languages and frameworks. Everything seemed fascinating, new, and all I wanted to do was explore that. It was, for a few years, something close to an all-consuming focus.

Now? Not so much. I can't remember the last time I built a toy webapp over a weekend. ¹ If I'm reading something related to engineering, it's more likely something fuzzy or soft rather than a piece of research or a tutorial on a new tech stack. The obsession and fascination is, if not entirely gone, then in an indefinite quiescence.

That's uncomfortable to write. We get signals all around us – from blogs, job postings, books, TED talks – about passion. We should cultivate it, and, if we don't experience it, should find a new line of work. I had to fight myself to not add some obligatory apology to the preceding paragraph - I'm still good at what I do, people like me, I do good work, etc – as if not being passionate is something I should apologize for.

I think this focus on passion is mostly wrongheaded. I'm not going to argue that general point here. Instead, I want to dig into a couple aspects of this narrative.

Won't I hate my job if I'm not passionate about it?

There's a certain false dichotomy that I see in discussions on passion and software careers.

On one side, we have a passionate engineer who lives and breathes code, puts in long hours at a day job, makes groundbreaking side projects or open source contributions during free time, gives conference talks and so on. Similar to how we might think of certain artists or authors, code is life, life is code. ²

The alternative is a sort of mediocre tedium. While not cut out for the field (by dearth of passion), this person might learn one framework well enough to get hired. Maybe the most they can hope for is a sympathy promotion to senior amid a career of drudgery. People are all passionate about something; failure to be passionate about your career means that you're not in the right career.

I think this is a harmful dichotomy. A profession can be a net positive contribution to your life – bringing fulfillment, challenge, even joy – without being a singular all-consuming focus. Blogs, internet discussions and so on don't always capture this, but I'd argue that it's a more common case among working developers than either of the two extremes above (based on my own experience, anyway). I know that my grandparents (for example) enjoyed their work and derived meaning and satisfaction from it, but I would not for a second think of asking my grandad if his work (maintaining telephone wiring and infrastructure) was his passion in life.

As I said above, I wouldn't describe myself as passionate. I also really enjoy my work. I like being part of a bigger whole (the company); it's really satisfying to look at the cool things that the company does and know that I contributed to them. I like interacting with my coworkers; they're good and fun people. I get to be creative when designing systems and solutions to problems. I get to disappear into the zone for a few hours a week writing code. I've grown and improved throughout my career, and continue to do so. It's a positive, fulfilling part of my life, among many other things that take me well away from it.

Won't I be a failure if I'm not passionate?

This one's a little tougher.

If we have two developers of equal aptitude, start them from the same starting point, have one put in 40 hours/week, and the other put in 80 hours/week, who will be ahead in 5 years? Overly simplistic, but also something I see a lot in discussions.

There's a core of this argument that's appealing. Practice helps us get better, and someone putting in more practice could be expected to get better faster than someone putting in less practice. There's nuance to this that makes things murky.

Not all practice is the same. If all I do is play the same scales on my piano, I'm not going to magically be able to play Chopin one day. If I'm being paid to work with a large team to maintain and extend a mature, complex, mission-critical enterprise system, writing a "Hello, world!" webapp in a technology my team will never use may have a middling impact or no impact at all on my job performance.

For senior people, hard technical skills stop being the limiter for career growth. It's important to be comfortable with hands-on work, of course, but it's also important to be able to lead when necessary, mentor and help less senior engineers grow, advocate for your own work to leadership, and think architecturally and strategically about how future work relates to your employer's goals. Passion projects – quite often one-dimensionally technical – will often not address these limiters.

Finally, it's important to acknowledge that there is some truth in here. Passion projects sometimes become well-loved open source libraries, lucrative SaaS products, or otherwise things that substantially benefit their creators. For people just starting out, when technical skills are a primary limiter, the payoff for extra practice, even if it amounts to nothing beyond a hello world app, is much clearer than it is for senior people. While it isn't universal or linear, there is a payoff to extra practice. This is fine. We are not failures because there are other developers who are more skilled or accomplished than we are. ³

Conclusion

It was (and still is) unsettling for me to acknowledge to myself that I wasn't passionate about CS in the way that I used to be. I'm sure it's even worse for people who never were passionate about it. I wanted to write this to reinforce that this it's OK for software to not be your passion if you're a developer. Common, even. You can still grow as a developer. You can still be a valuable member of your team. You can still genuinely enjoy your work. You can still have a future in the industry. You aren't in the wrong field.

For me, the amount of pleasure I get from these essentially "Hello, world!" projects diminished significantly after I put in the time to really deeply learn – over years – a couple of different languages and frameworks. Intro projects can be fun, but will not provide more than a surface level understanding of the technologies used. This will be unsatisfying to people who enjoy a deep understanding of their tools, and also makes these sort of projects highly overrated as ways to "stay up to date on the latest technologies" ↩
There are absolutely people who fit the passionate engineer stereotype. They have an unaffected, intrinsic curiosity and fascination with code, and get ample and joyful returns for the part of their life they dedicate to it. Some people, lacking passion in this sense, are driven enough to work really hard anyway to advance. It's important to acknowledge this; you are likely to meet and work with these people at some point in your career, and it's to your benefit to do so without feeling defensive about their dedication. ↩
Actually accepting this and keeping it as a stable point of self-regard – even when working with people who are clearly a lot better at engineering than I am – was the work of years for me. The payoff was worth it, though. ↩

Interview Feedback Antipatterns

Kevan Carstensen — Sat, 17 Oct 2020 23:33:05 +0000

One of the more valuable training exercises I've had in my career was a slide deck on interview feedback. It reinforced two points that I try to keep in mind when conducting interviews and giving interview feedback:

My goal when interviewing is to evaluate the person for the job I'm interviewing them for.
My feedback and conclusions should relate specifically to the job the candidate is interviewing for.

A lot of common interview feedback (often negative feedback) doesn't do this, being either generally vague or specific but not obviously related to the position.

When I see these types of statements in my own feedback, it's a cue to think more carefully about the candidate. Often my point can be made more precise; this helps make for a more productive interview feedback session. Sometimes vague sentiments or gut feelings vanish under closer examination; when this happens, I learn something important about my blind spots and biases.

I also try to keep this in mind when listening to the feedback of others during candidate sync ups. If I hear a negative appraisal of a candidate without specific, clearly relevant justification, it's a cue to ask follow up questions.

Some examples that come to mind for me (having seen/heard them fairly commonly): ¹

Many points about communication skills. ²
Lack of "passion" / lack of growth mentality. ³
Many things related to culture fit. ⁴
Whether the candidate seems excited about the position. ⁵

I would love to read about how other developers handle this. Do you have particular types of feedback you take as a cue to go back and think more about a candidate, or ask other people to do so? Do you have an engineering culture where you feel empowered to do this?

I don't mean to imply that these are always invalid things to consider in feedback. Only that they are frequently (in my experience) raised as self-evident reasons to pass on a candidate, without specifics and without reflection about whether they are actually relevant for the job. ↩
"Poor communication skills" is not great feedback. "The candidate was not able to clearly articulate the service boundaries of his design in our panel; he would be expected to do this as a principal engineer here" is better; it provides more specifics, and explains why this concern is relevant. ↩
Often, in my experience, raised for more senior, older, or non-traditional candidates who don't have a bunch of GitHub repositories showing off side projects and the like. Does not by itself say anything about how well the candidate would work as an employee. ↩
Self-evident, I hope. ↩
A great many developers manage to be good at their jobs without being excited about them. Some developers may be excited without reading that way (e.g., they're quieter, mellower). It is also really easy to fake being excited. This just doesn't seem like a great thing to look at. ↩