InRhythm

Your partners in accelerated digital transformation

Software Engineering

Why I started coding (Part 2)

This post is another by InRhythm’s own Sari Morninghawk. For the full post and additional links, check out the original “Back-in-the-Day App Engineer to Web Developer Or Why I Started Coding (Part II)” on her website.

So there I was, my first job as a programmer, working at a large financial institution where my title was Senior Applications Engineer! Just the day before I was ringing up customers at the Green Grocer down the street, mopping the floor if I had the closing shift. Why did I start coding? My income was 4-times what I was making at the grocery. That’s 400% in one-fell-swoop with no more floor mopping! But, I must admit, I was a little over my head. I had to learn a lot of things on the job — and very quickly. Fortunately, most engineers are wonderfully helpful if you’re just willing to ask.

Back-in-the-Day Programming

There are always buzzwords. Currently they include “mobile first”, “artificial intelligence” (AI), “microservices”, and “framework”. One of the buzzwords at my first tech job in the ’90s was “client-server”, mostly because small businesses and even individuals could now own a computer, creating desktop applications or “clients” that never before existed.

Continue the story on Sari’s blog…

Smart Interview Questions

Searching for a job sucks, especially early in your career. Most applications never get a response, most interviews don’t turn into offers. When you’re unemployed and need to find something quickly to cover your living expenses, you may not be able to afford to be picky about your employer.

However, when you’re comfortably employed at a job that doesn’t leave you satisfied, you have more leeway to find a new environment that will help you thrive. Your job is your biggest investment in yourself, and staying a job that restricts your growth—especially early in your career—can have lasting impact on your income and skills. Demand for highly effective and motivated programmers currently outpaces the available supply, forcing companies to compete for our time in the form of benefits, salary, and environment. However, it can be hard to evaluate how happy you’ll be at a company before joining.

In my career (as of April 2018) I’ve worked for 6 different companies. I’ve helped run a startup, worked for a small local business, a Y Combinator company, two other startups of different scales, and a Fortune 100 company. I’ve worked with hardware, agriculture-tech, ad-tech, health-tech, and at a financial company. I feel this has given me a relatively uncommon perspective on how companies of different sizes, in different industries, and at different points in the development lifecycle operate, and changing jobs 6 times has given me a lot of experience interviewing.

To this end, I’ve compiled a list of questions that I ask, wish I had asked, or plan to ask in the future, with additional details about what kinds of answers I’m hoping to hear. Here’s the first one:

How long do you expect it would take me to deploy my first change? To become productive? To understand the codebase?

How long it takes a new developer to deploy their first change is a decent proxy for overall health of the team. The faster you can deploy your first change, the more likely they are to have well defined tasks (that are well understood and prioritized), a deployment process that’s simple enough for a new person to perform, and confidence that somebody unfamiliar with the overall system will be able to make a change.

Asking how long before they expect you to become productive will help you set expectations. For junior or mid level roles, I don’t think it’s uncommon for this to be measured in months. The question will help you and your employer get on the same page, which I think helps stave off some of the impostor syndrome that can come with familiarizing yourself with a new codebase–especially if you haven’t experienced that many times.

For many teams, there likely isn’t a single person who understands the entire codebase. In frontend it’s more likely that you’ll eventually develop and understanding of the whole because it’s less likely to contain specialized expert knowledge. Reactions to this question can help you gauge how the developers feel about the code they work on.

This post is brought to you by InRhythm’s own Carl Vitullo. Follow him on Twitter for more brilliant thinking like this.

Overly Defensive Programming – The Video

Recently we shared an article written by InRhythm’s own Carl Vitullo on Overly Defensive Programming. That article was the basis for a talk he gave at JavaScript.NYC last month and the video is finally available! If you’re not one of the people lucky enough to have witnessed the talk in person, now you can finally bask in it’s glory!

Why I started coding (Part 1)

This post is another by InRhythm’s own Sari Morninghawk. For the full post and additional links, check out the original “The San Francisco dot–com Boom of the Mid–90s Or Why I Started Coding (Part I)” on her website.

In 1992, I was a single mother of one in San Francisco, working as a musician. To clarify, I was doing work as a musician, but there was hardly a paycheck involved. So, I also needed a “day job” to pay the bills. My hard-working, straight-A student daughter was attending a fancy, expensive high school on a scholarship that was larger than my annual income. In other words, my daughter made more money than me through most of her high school years. I had nothing saved for her to attend college, and unless I figured out something else to do for money that wasn’t waiting tables, stocking shelves, or putting files in alphabetical order, then I would continue to live hand-to-mouth with a big fat zero in my non-existent savings account. If you looked at the economics of the Bay Area in ’92, you saw the early rumblings of the dot-com boom that was about to happen. If you wanted to make some money living in San Francisco, you’d better know some computer science. I started an evening class at SF Community College.

Continue the story on Sari’s blog…