Tag: choosing technology

Learn SQL

Dear new developer,

It’s a good idea to learn SQL (which stands for structured query language). This is the language that the vast majority of data is stored in for most companies. The reason for this is that relational databases (which is what SQL is the main interface for) are very good at a wide variety of data storage. Sure, at the edges of speed, scale and functionality there are other solutions, but you should reach for them when the relational database falls short, not at first.

You don’t need to be an expert at SQL, though it’s a mindbending way to interact with data, so you might want to put studying it on your list. Instead of being procedural or functional, SQL is set based. I confess, I’ve been using it for decades and still haven’t mastered it.

If you are using a modern language, there are often frameworks that sit between you and the database (for example, ActiveRecord for Rails, Hibernate for Java, SQLAlchemy for Python). These are helpful because they make simple operations simpler. If you want to look something up via primary key or a simple query, these tools can help. But if things get harder (joining across multiple tables, database specific functions) the abstraction breaks down. This is where knowing some SQL can be helpful.

There are also times when you are running queries that are punishing using a framework. For example, if you wanted to sum across a set of orders in a day to get a daily total, a naive framework would have to load all the data for the orders and then sum up the order value in memory. A more sophisticated framework would be able to generate SQL summing up the values in the database for you. Unfortunately, it’s hard to know whether the framework you are using is naive or sophisticated. But dropping into SQL will always work.

I have also found that some systems have a lot of non intuitive operations, but that at the end of the day, the magic is built on code and data storage. By looking at the data storage, you can understand some of the operations that these frameworks take care of for you. For instance, for a long time, rails migrations were magical to me. When I took a look at the database, it became clear that a fundamental piece of rails migrations was the datetime portion of the migration name stored in the database. When I got into a weird state because of running migrations then switching branches then re-running migrations, this understanding of the data structure behind them helped me out.

Some good resources to learn SQL:

One final note. People have very strong opinions on the type of SQL database they use (a commercial offering like SQL Server or Oracle, or an open source solution like MySQL or PostgreSQL). As a new developer, you want to learn whatever your company is using. Honestly, the difference between them at the basic SQL level just isn’t that large. They start to differ in more advanced SQL functions and other performance and administration concerns. But that’ll matter later in your career.

Sincerely,

Dan

Write a technical ebook

Dear new developer,

I suggest you take some of your ample free time (if you have it) and write a technical book. I’ve written one book and doing so gives you a deep understanding both of the technology you choose to write about and of the difficulties of doing so. It will give you instant credibility should you choose to pursue a job related to the technology. You can use it to make connections and give speeches at meetups.It may even make you some money, but don’t count on that.

Pick a technology that you use at work or on a side project. Characteristics you are looking for:

  • few books have been written about the topic
  • you are really really interested in the topic and want to master it
  • it is something you use regularly
  • the technology is either really new (and you think you might be able to do multiple revisions) like React, or is really old and slow moving (like bash)
  • it’s something relatively popular or new

I made a number of mistakes when I wrote a book about command line hooks in cordova (which is a framework for writing mobile applications). The mistakes I made included:

  • the market for cordova books was small, and the subset of people interested in automation of cordova actions was even smaller (even so, I found about 70 people willing to pay for the book)
  • I picked the technology because we were using it at the time, but after one project we stopped. I wasn’t really interested in mobile development, and so never updated the book.

Topics that aren’t technical are more evergreen (how to manage a software team has changed in the last 20 years, but how to build a javascript application how changed in the last 12 months), but there are more books out there about them as a result. Technical books have a shorter shelf life but also have less competition.

However, if you can find a topic you want to write about, don’t start writing the book from scratch. Instead, outline it and write a number of pieces of the book. An easy way to do this is to create a category on your blog (you have a blog, right?) and start writing regularly about the topic. Write an outline and add blog posts based on the outline.

After four or five blog posts, you’ll know if this is a technology you want to dig into and publish a book about. Keep writing the posts, but start looking for communities where the technology is published. Start answering questions about it on the forum and/or your blog. Set up an email list to capture people who are interested in your topic and visit your blog.

The risk is low. If, on the other hand, you write two articles about technology X and you are bored out of your mind, then just stop and don’t create the ebook.

Once you have about 20 posts, you can start thinking about pulling them together to form an ebook (the exact number depends on the size of your topic). I used leanpub and had a great experience. Note that you’ll be entirely responsible for not only writing the book, but marketing it. However, you get to keep something like 90% of the price of the book. Leanpub can pull an RSS feed into the leanpub format and you can use it to suck down the posts you’ve been writing.

After you do that, it’s really about continuing to fill out the outline, updating your forum posts to include a link to your book site, and marketing the book. I’m no expert there, but made about $700 bucks from my ebook. I don’t think I ever calculated the exact hourly rate, but I can say with confidence that it was far lower than I could have made contracting.

So, in the end, why is it valuable? I think writing a book, even a 40 page ebook like I did, challenges you to think deeply (to understand the technology and convey it in a way that other people can understand) and broadly (similar to holding a really large software system in your mind). These are both really good skills to acquire.

Sincerely,

Dan

Deep vs wide experience

Dear new developer,

You have only a finite amount of time, and the world is large.

Technology changes so often and so fast that it can often feel like there is not enough time. Here are two strategies.

The first is to focus on fundamentals. Yes, there’s a new javascript framework. But it will still have a way to represent data, it will still use algorithms, it will still store data durably, it will still have a build system. Learn these fundamentals for two different solutions and you will start to see patterns that will allow you to pick up new languages/frameworks more easily (because you can map back to an existing solution).

The second is to choose whether you want to go deep or go wide. Going deep is focusing on one domain or language and truly achieve mastery. This is a project of years and experience. This path will lead you to interesting jobs and big paychecks, if you pick the right area. If you choose poorly, you might have only a few employers to pick from. Working for a product company is the best way to go deep.

Going wide will mean that you never achieve true mastery. You will however, learn to pick up new skills quickly. You’ll learn to map between two dissimilar situations. You’ll start to see patterns across software development and business. You’ll always be more of a generalist than a specialist, and that will limit some job opportunities. Working for a consulting company is a great way to go wide.

Neither of these is a better path than the other, and you can, especially in your early career, switch between them. Try them both on and choose consciously.

Sincerely,

Dan