Listen to podcasts

Dear new developer,

Depending on what your life looks like, you may have some time where your body is occupied, but your mind is not. At least not 100%. Tasks like doing the dishes, running and driving all fall into that category.

In this extra time, you may want to listen to podcasts. Most smartphones have an app but you can install your own (I like PodcastAddict). Good podcasts:

  • expose you to new ideas (so you don’t remain an expert beginner).
  • reveal new technologies and tools.
  • are a source of wisdom and experience.

I think there are three categories of podcasts that you can listen to that will help your development career (I’m omitting lots of great podcasts by adding that clause).

  • Domain specific. If you work at a startup disrupting the real estate industry, listen to a podcast or two about real estate. Car insurance? Fashion? In each case you can find podcasts that are focused on your domain. You don’t need to be an expert in your domain, but the more you understand of it, the more able you’ll be to implement software in that domain and communicate with subject matter experts (SME) about the nuances of the problem space.
  • Technology specific. If you are writing code in Rails, listen to podcasts about Ruby and Rails development.  The same for JavaScript or C or Erlang or Lisp or … These podcasts will be helpful in terms of helping elevate your development skills in the particular language. They’ll also be helpful in making you aware of tools and libraries which will make you more effective. I like to email myself notes when I listen to these kinds of podcasts.
  • General software development. These podcasts talk about software development in general. Some are more technical and cover architecture or other interesting problems. Some are less technical and discuss the human side of software development. But these are the podcasts you are least likely to unsubscribe from when you switch jobs, because the topics are broad enough.

Don’t feel that you have to listen to every podcast episode. For these types of podcasts I don’t listen to every episode of any podcast, because no podcast is specific enough to what I need. I pick and choose based on the show notes and the guests. And don’t feel bad about unsubscribing when you switch industries or if a podcast is no longer of interest.

Sincerely,

Dan

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

Don’t be afraid to “fail”

This is a guest post from Cierra Nease. Enjoy.

Dear new developer,

“Failures” as a new developer are plenty — but you might be asking, why is “failures” in quotes? To fail something is dependent upon one’s perspective. The only true failure is to quit working towards success. Every failure brings a small success in that you learn what the right answer is not. How can you problem solve without a way of marking off solutions that do not work? A failure is simply a solution that didn’t work at that specific time.

We can all talk about how learning and growth come from having failures, but it’s hard to remember that when you feel like you are a failure. Failures do not inherently make the person a failure, and it can be hard to make that distinction in the moment. Sometimes we need someone else to remind us of this.

I’ve had a lot of people in life reiterate this concept to me. The most recent person was a fellow developer named Mike on the Denver light rail. It’s funny what will happen when people participate in communicating and interacting with each other, but that is for another blog post entirely. For now, let’s go back to Mike. Mike overheard me talking to another passenger about being in a bootcamp. When I finished my conversation, he handed me a card and said he’d love to answer any questions I have about becoming a developer. I elaborated on some of my bootcamp experience, which happens to be full of failures.

Mike expressed his number one piece of advice for any developer, telling me: “whatever you do, don’t be afraid to fail.” We started talking about this in depth, and it really resonated with me for the rest of the evening. As a new developer, you really only see senior developers’ successes. Each developer goes through their own learning process which does include failures.

The failures that lead to success don’t stop when you become a “better” developer. If you are looking for a point when you quit failing as a developer, then you are looking for the wrong thing. The more you fail, the more you learn. The more you learn, the more you grow. The more you grow, the better the developer you become.

As a newer developer, I look forward to all of the opportunities to learn, grow, and accept my failures as the wrong solution instead of accepting them as a personal characteristic.

Sincerely,

Cierra

Cierra Nease is currently studying software development. She blogs at Cierra Codes 101.

Three Mantras to Live By

This is a guest post from Dave Mayer. Enjoy.

Dear New Dev-

After 22 years of ‘production level’ experience in the real world, I’m writing to share three mantras that have led to more happiness and more success for us.

To be clear, these are DAILY mantras. Not weekly, not monthly, not annually. Daily.

They are:

  • Surround yourself with people smarter than you
  • Build community and give without expecting anything in return
  • Listen to your gut, without exception.

Surround yourself every-damn-day with people who are smarter than you

You’ll never be, nor should you, be the smartest person in the room. Confucius reportedly wrote ‘if you are the smartest person in the room, you’re in the wrong room’. Regardless of who wrote those words, they couldn’t be more true. Since high school, I’ve always known that I was smart, but I was also clear that I was not the best at everything and that everyone had something to help me learn or to help me become a better student or a better human.

I’m not suggesting you surround yourself with jerks with a ton of pretense who can’t stop talking about themselves and how smart they are, I’m suggesting that you learn to say ‘I don’t know’, ‘wow, that’s cool, tell me more’, and ‘yes, I could use some help’. Knowing that you will never have all the answers, that it’s okay to ask for help, and having an insatiable curiosity about engineering, life, music and anything that is important to you will get you far in life.

Build community and give without expecting anything in return

In 2006, going into the ‘Great Recession’ we sat in the back of the room at the Boulder-Denver New Tech Meetup and listened to Brad Feld talk about bringing people together and building community (in whatever area and subject that matters to you) with no expectation of anything in return. This idea of #GivingFirst was revolutionary to us thirteen years ago, and it’s been a life-changer for us. It’s a super simple yet elegant idea of walking into a room and asking how you can help someone solve their biggest challenges rather than where-do-they-work-or-what-kind-of-car-do-they-drive. We wrote a detailed article about this topic for CTO Lunches Magazine on page 29- give it a read. It’s truly been life-changing to help others and embrace that as a BUSINESS philosophy, not just a life philosophy. It will all come back to you, you just don’t know how or when, and that’s OK.

Listen to your gut, every day without exception

It sounds simple, but not everyone does it. Your intuition is always right, yet folks second-guess themselves, rethink things and question their own motivations. That’s all healthy, and yes, you should ‘sleep on it’, whatever ‘it’ is. Space gives clarity. In large decisions, I ALWAYS take at least 24 hours to think on what the right answer is for me, and to listen to my gut. It’s NEVER failed me and it will never fail you. I promise.

I hope you will consider even one of these three mantras. You won’t be disappointed.

– Dave

Dave Mayer is a long time community building advocate, and by day he’s CEO of Technical Integrity, a boutique recruiting firm focused on building diverse executive and technical teams for startups in Colorado and beyond.

Read great books about software development

Dear new developer,

Read books about software development.

Seriously.

Now, you won’t learn the latest techniques from books. Those will live online in blogs or videos (or in papers, if you work in an area like machine learning influenced by academia).

Nor will you learn a lot that you can put to immediate use to solve the problem right in front of you (that will probably be found in online docs, github issues, or stackoverflow).

What you’ll learn from the great books of software engineering are timeless practices. You’ll also learn how to dig in to a topic deeply, and how to take what is in the book and discern what can be applied to your work (and what should be ignored). I’ve had discussion groups about software books, which can be a fun way for people to bring their own experience (and be accountable; sometimes great books can be hard to get through).

There are a number of great books out there, but here are three:

  • The Mythical Man Month
    • Covers a major software project from the 1960s, including how hard it is to build good software and the fact that when a project is late, adding more developers will increase communication needs, which will delay it further.
  • The Pragmatic Programmer
    • Discusses software best practices and ways to level up your software development. Has a great set of checklists.
  • Refactoring
    • Talks about the practice of refactoring, which can be thought of as software maintenance (in the same way that you need to take care of your car, you need to take care of software). How to do it, when to do it, how to talk about it–these are all covered.

As a bonus, here’s a great software essay on the essential complexity of building software, There’s No Silver Bullet.

I suggest asking engineers you respect what books they’d recommend you read to deepen your understanding of your craft.

Sincerely,

Dan

On surviving your first year as a developer

Dear new developer,

This post covers some great tips on getting through your first year. It starts off ominously:

The first year as a programmer is one of the most frustrating things a homo sapien can experience. You’re thrust from the world of ambiguous human communication into the icy waters of cold, hard correctness. There is no compromise with the machine. It does exactly what you tell it to, no more, no less.

But then moves to some good advice, about advice:

There are very few absolutes when it comes to practical programming. A Technical opinions of developers are based on their experiences, the books they’ve read and the technologies they happened to work with. No one does a thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.

This is so true. Everyone’s opinion is path dependent. I was a MySQL user for years and thought it was the best open source database, until a chance comment from someone I was chatting with at a meetup (see, you should attend a meetup) mentioned that PostgreSQL has transactional DDL. That is, you can alter a table as part of a transaction, and they roll it back. (Happy to report that MySQL has made progress on this, though I don’t believe they are at feature parity yet.) If I hadn’t run into that meetup participant, it is unlikely I would have learned that nuance.

Multiply that experience by the hundreds of decisions a developer makes every year based on their knowledge, their problem space and their work environment and you can see how different advice can be. And to be fair, how it can all be valid, based on context.

The post also covers ego-less coding, what to learn, and the joy of bug hunting. The whole post, “Survive your first year as a programmer”, is worth a read.

Sincerely,

Dan

How to learn things, fast

Dear new developer,

I enjoyed this post about how to learn. While the author toots his own horn a bit much for me, he makes some very valid points about how to learn. Most importantly, you want to learn using the best resource. What is best?

The best resource is a bit of a lie – it’s really just the one that’s best for you, given your prior experiences and the medium you enjoy. You’ll usually only know you found it in hindsight.

And, once you’ve gained an intermediate level understanding of what you are trying to learn, you should:

Stop. This is counter-intuitive, but unless you want to become a master at something (besides learning), you really just want to know everything at an intermediate level.

The whole post, “How to learn things at 1000x the speed”, is worth checking out.

Sincerely,

Dan