Learn SQL with sqlite

Dear new developer,

I wrote a post about learning SQL a while back. I posted the link in Lobste.rs, an online community, which generated some interesting comments.

One of them was that sqlite was a better way to learn SQL than using PostgreSQL or MySQL. This is due to the fact that there are some administrative tasks that could lead to possible confusion with those more powerful SQL databases.

I downloaded sqlite and agree that it is a super simple, low risk way for new developers to learn SQL. It’s a single zip file and you can create tables and run through tutorials without having to worry about what port something is listening on.

The flip side is it won’t be as applicable to your on the job experience. There are definitely people out there building wonderful solutions with sqlite. But I think for most typical new developers, an experience with a client server relational database like PostgreSQL or MySQL are more likely.

Here’s the download link, you most likely want the tools precompiled binary. And here’s a quickstart guide.

Sincerely,

Dan

The care and feeding of developers

Dear new developer,

I thought this post from 2012, about what software developers want, was penetrating and relevant. This passage resonated for me:

And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.

Even as a new developer, you’re constantly making small creative decisions (naming a variable, for example). This is part of what makes software development so fulfilling and fun. Any place where you are solely an order taker with no opportunity to add your unique perspective is a place I wouldn’t want to work. (Such a place would remind me of L. Bob Rife’s plans. And if you haven’t read Snow Crash, highly recommended.)

The whole post, “The care and feeding of software engineers (or, why engineers are grumpy)”, is worth a read.

Sincerely,

Dan

No choice is permanent

Dear new developer,

Sometimes when you are thinking about a new job or shifting to a new position in a company, it can feel overwhelming. What if I make the wrong choice? At least, I’ve often felt that way.

Every choice you make has effects. When you choose to study ruby, you can’t also study python (opportunity cost!). When you work at a company, you will learn how that company works, but not about how other companies work.

I sometimes have FOMO (fear of missing out) when I commit to one path. “What would have happened if I had gone down another path?” I wonder.

That’s OK. I think it’s human. But you still have to make a choice.

I remember talking to a friend once about making decisions. She said that she likes to make a decision as late as possible. I think this is a good practice. Gather the data you need and can get without asymetric effort (that is, the larger the issue is, the more effort you should put in–I should invest more effort into learning about joining a new company than I should into learning a new project within the same company, for example). Make the decision as late as you can, because you’ll learn more as time goes on.

However.

It’s also important to realize that few decisions are permanent, especially as a new developer in your career. You’ll have flexibility in terms of geography, type of company, type of job, size of company, business domain. Some shifts may be easier because of your history and the aforementioned effects (shifting from being a web developer to being a backend engineer), some may be harder (changing from a web developer into an embedded systems engineer), some may be well nigh impossible (changing from a web developer into a compiler developer), but some change will be available to you.

What this means to me is that decisions which seem crucial, critical, life-changing, are, but that if you make an incorrect decision you can change. And that, for me, takes some of the pressure off.

Sincerely,

Dan

PS, as Kendall pointed out, there are some decisions that are essentially permanent. But most career decisions aren’t.

Cultivate the Skill of Undivided Attention, or “Deep Work”

This is a guest post from Josh Thompson. Enjoy.

Dear New Developer,

You know that there’s a chasm between your skill level and that of the mythical “senior software developer”.

If you build a list of topics you encounter on your job that, if learned to a deep enough level, would put you on the same level as a senior developer, you’ll end up even more demoralized than before compiling that list.

No need to assemble this list yourself! I’ve done it for you.

Here’s the list of topics that I’d need to dedicate significant time to, in order to close the gap between me and the senior developers on our team, that I’ve encountered in my last two days of work:

Breaking complex unknowns into simpler unknowns that can be further split into individual tickets
Adding tests to complex, legacy code, to guide further refactoring of said code.
Using `grep` to comb through server logs to diagnose a hard-to-identify-and-reproduce problem
Provisioning new servers
Building bash scripts to automate complex workflows
Digging into gem source code to can shed gem dependencies while maintaining certain features
Understanding indexing well enough to see that certain queries that we thought were using indexes were not, and fix this oversight index on the fly, without causing any blips in availability

Each of these line-items has many books written about the topic.

It seems like you could fill a bookshelf with books that address knowledge senior developers have available to them inside their own heads.

It takes me long enough to work through a single book, so imagining a bookshelf of extra-curricular reading is quite daunting.

It might feel daunting for you, too.

Leading vs. lagging indicators

The above list of skills is a lagging indicator of the underlying knowledge. We should not target improving lagging indicators, we should improve leading indicators.

Josh, what is this ‘lagging and leading indicator’ stuff?

Great question!

A lagging indicator is “evidence that something has already happened.”

If you got an A on a test, that is evidence that you learned the material.

A leading indicator is “evidence that something will likely happen”.

If you want to get an A on a test, you should study in a similar way as others who have gotten an A on that test. Maybe you need ten high-quality hours of study to get an A, so “number of high-quality study hours” would be a leading indicator of your grade.

We no longer take tests (phew. I hated taking tests.) but we get mini-tests of our knowledge, daily. We’re paid to solve problems, which often require learning new things.

Rather than focusing on a list of things other developers have learned, and targeting that list, I humbly propose that a leading indicator of acquiring this kind of knowledge is “hours per week spent in a state of intentional deep work”.

The above list of topics are lagging indicators of a high degree of technical knowledge. Someone acquires the knowledge, then, and only then, can demonstrate that they have it.

Leading indicators are “predictive”, in that if you can identify correctly those indicators, you can predict the outcome of the issue at hand.

In this case, the issue at hand is “become significantly more experienced in the domain of software development”.

I propose that a leading indicator of someone gaining these skills is the amount of time they spend in a state of deep work.

I’d encourage you to read Deep Work: Rules for Focused Success in a Distracted World. The author makes a case for deep work being a key role in the success of “knowledge workers” (which includes many types of work, including, of course, software development.)

If you’d rather not read the book, here’s the gist, from this summary of the book:

In order to produce the absolute best stuff you’re capable of, you need to commit to deep work.
The ability to quickly master hard things and the ability to produce at an elite level, in terms of both quality and speed, are two core abilities for thriving in today’s economy.
“To learn hard things quickly, you must focus intensely without distraction.”
“Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life.”
“The key to developing a deep work habit is to move beyond good intentions and add routines and rituals to your working life designed to minimize the amount of your limited willpower necessary to transition into and maintain a state of unbroken concentration.”

Imagine two equally knowledgeable early-career software developers. They have the exact same skills on January 1, 2020. If the first software developer spends four hours a week doing deep work, while the second software developer spends fifteen hours a week doing deep work, their trajectories will be quite different, and that second developer will quickly gain technical knowledge and proficiencies.

So, if you’re an early-career software developer, track the time you spend doing deep work. That has you focusing on a leading indicator of growing in your skills.

At that point, you’ll benefit from Peter Drucker’s assessment:

What is measured, improves.

You’ll track how many hours you spend doing deep work, and by tracking it, you’ll do more and more of it.

In conclusion

Do more deep work, and over a year or two years, your skills will grow much faster than those doing less deep work. Eventually, you might find that you’re doing the work of a senior developer!

Good luck!

-Josh

Josh looks forward to being a senior developer some day. He’s only a few years into his career in the software development industry, but enjoys getting to bring knowledge and skills from his prior careers into his current role. He lives in (and works remotely from) Golden, CO, with his wife and loves to rock climb and read books, and can often be spotted in Denver-area climbing gyms or local crags.

Types of companies that use software

Dear new developer,

In my experience, three types of companies use software. Software is as prevalent as accounting, so every company uses it in some way.

Those that sell software to help build software, software product companies. Examples from my career: Oracle.
Those that sell software, often called product companies. Examples from my career: The Food Corridor, Katasi.
Those that sell hours or knowledge of developers and other software professionals (PMs, designers, etc). Examples from my career: XOR, Culture Foundry.
Those that sell anything else and use software to help. Basically almost every other business. Examples from my career: 8z, Phoenix Enterprises.

As a new software developer consider where to seek employment, they each have strengths and weaknesses. It’s worth talking about these so you can find a company that aligns with where you want to go (remember, every place has its warts).

Software product companies

Pluses:

You are the end user, so having user empathy is easy.
Software developers are highly valued within the organization.
Lots of focus on building out higher leverage software processes.
When successful, these companies have great gross margins and can afford good pay and benefits.

Minuses:

Developers often start companies like this, so there’s a lot of competition.
Jobs are desirable, so may have a long interview process with a lot of hoops.

Product companies

Pluses:

You can go deep into a particular business domain.
Software developers are key components of such a company’s success, and are treated like it.
They often have recurring revenue and a business model that allows for good pay and benefits.

Minuses:

Can be harder to get hired than in other types of companies because jobs are more desirable.
May be boring to be in same domain for long periods of time.
May use older technology depending on the age of the company. Legacy systems make money!

Consulting

You often skim domains, so you can get some variety of experience in different types of businesses.
Always new projects to be on, often means new technology to evaluate and learn.
An hour worked is often an hour billed, so your efforts are directly related to revenue.
If you are looking to go off on your own, these consulting businesses are easy to start (no overhead, no investment in building a product, you just need a laptop and an internet connection and someone willing to hire you).

Minuses:

As an employee, you need to realize that there is no real exit strategy for the founder(s). Which is fine as long as the founder is still interested in running the business.
There is limited recurring revenue, which means that the business goes through cycles of grow -> shrink -> grow -> shrink.
Lots of lots of effort in finding new projects and clients.
Because of the sales cycle, it is hard to specialize as a consulting company, sometimes you take projects because you have to pay bills.
Can have tight deadlines and lower profitability, which affects your experience as a developer.

The rest

Pluses:

Often have stable businesses.
Software quality and process tends to lower in non software focused companies, making it easier to outperform competition.
Software quality could be competitive advantage.
You’ll have the chance to learn about and work in a non software business domain.

Minuses

Developers won’t be as highly valued at some other types of companies.
IT/software can be seen as an expense rather than a revenue generator, especially if not affiliated with revenue side of the business.
Sometimes you may be alone or in the company of expert beginners.

Each of these types of companies has different strengths and can be a good fit for you early in your career. Consider what excites you and what is available in your job market when you make the choice. It’s also worth reminding yourself that since as a new developer you’re judged on potential, any choice you make to go into one type of company or another isn’t permanent!

Sincerely,

Dan

Web APIs for new developers

Dear new developer,

Chances are high that you’ll be working with other code as a developer.

I remember when I was first starting out and saw the acronym API everywhere. I had no idea what it stood for. In case you are in the same boat, it means Appliciation Programming Interface. What that means is it is a defined way for your code to call into another piece of code.

One of the most common ways to do so in an interconnected time is via a web API. A web API (as I define it) provides significant functionality for your application, across the internet, over HTTP. You may or may not control the API, and you may or may not use an SDK to access the API. (There are, of course, many other ways to integrate other functionality into your application, depending on what you’re doing.)

This article does a good job of discussing some of what you should be aware of when you are accessing web APIs. In particular:

First, a clarification: the term API is used to refer to lots of different things, and its emphasis has shifted a great deal over the years. If you’ve learned anything about Object Oriented development, you may be familiar with APIs as code components that have well-defined interfaces, allowing “customer” code to access the features and functionalities within a system. These APIs usually involve objects and methods / functions. This is not the type of API we’re going to talk about in this article. 😅

In this article, we’re dealing with the kind of API you use to manage access to data and services over the web. If you’ve come across the terms HTTP API or REST API, that’s what we’re talking about. With this type of API, client apps make requests to endpoints to carry out operations on data. An example would be a database for a shop that has a web app and a mobile app – with an API managing access to the data from both apps.

The article goes on to discuss different concerns you should have as a developer interacting with web APIs.

The power of web APIs is that you can gain access to a quite complicated system via a simple API call. Examples of this include:

Looking up stores or restaurants that are close to you (Google Maps)
Making a charge against a credit card (Stripe)
Sending a text message (Twilio)

These all used to be tremendously complicated tasks, sometimes taking weeks to months to set up. Now you can access them and put together an application that does all three in hours. We stand on the shoulders of giants, indeed.

You don’t just benefit from the API integration one time. The API provider has an incentive (especially you are paying them in data or money) to improve their service. And often you can get the benefits of that improvement without lifting a finger.

If you have a large task that you want to do as part of an application, it’s worth googling around a bit to see if someone has already encapsulated it in an API.

Sincerely,

Dan

Learn to type quickly

Dear new developer,

Coding is so much more than typing into a computer. Other things that matter:

knowing who to talk to
what to build
when to discuss high and low level concepts
other processes like testing and documentation
communicating progress
course correcting when a project goes awry

These are all skills you need to be a great developer.

However, just like knowing the command line and a text editor, knowing how to touch type will make you more effective. Touch typing is the ability to type without looking at the keyboard with all 10 of your fingers (if you don’t have use of all your fingers or you use fewer, you can still type quickly).

Typing well is especially important because many forms of communication are text based (slack, email, ticketing systems). But even for plain old coding, being a touch typer will help you be more effective. This is because you’ll be able to implement things more quickly. You should learn your keyboard shortcuts for commonly used programs too.

You can Google “practice touch typing” and check out several sites (paid and free) to improve your speed. There are also competitions out there like typeracer. I was lucky enough to learn to touch type in school, so I haven’t had to try any of these out.

However, a big caveat. If I had the choice between being a fast typer who didn’t understand a problem space or a slow typer who did understand a domain, I’d pick the latter. Often, the best code is no code. So, focus on understanding and then solving the problem. Make sure you make your fast typing skills work in service of solving the correct problem, so you can be the fast typer who does understand the problem space.

Sincerely,

Dan