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

Don’t try to change the tabbing / bracing style

This is a guest post from Andrew Rondeau. Enjoy.

Dear New Developer,

Don’t show up an a new job and immediately try to change the tabbing and/or bracing style. This is especially important if the codebase you work on has a very consistent style that all of the other developers follow.

Why? Tabbing and bracing styles are really a matter of personal preference. What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more important than having your favorite style. Furthermore, because tabbing and bracing styles are really a matter of personal preference, arguing with the more senior developers about this topic is a waste of everyones’ time. The senior developers, or your manager, will probably assume that you have poor time management skills, or that you get obsessed with details that don’t matter.

And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline. The problem is that some people really get irrationally attached to whichever style they are used to. These discussions don’t fix bugs or deliver features that the business needs to survive; thus, don’t waste time and stick with whatever tabbing and bracing style your codebase uses.

When is it important to discuss tabs versus spaces, or bracing styles, as a new developer? When a codebase has an inconsistent style, especially if it doesn’t match a team’s style guide! Politely point out to your manager, or lead, that there is a lot of inconsistent use of tabs and/or braces; and suggest a tool that will automatically reformat the code. Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple. At that point, it’s your manager or lead’s discretion if your team will adopt a new style.

If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. Why? Again, a consistent style is more important than being able to write code with your preferred tabbing or bracing style. Inconsistent code is harder to read, and confuses people about what the established style really is. It also tempts people to stick with their preferred style, instead of whatever the team agreed to. Instead, use an automated tool to reformat the code.

— Andrew

Andrew is the desktop client architect for Syncplicity, a file synchronization product. Here’s his LinkedIn profile.

Admit your weaknesses

Dear new developer,

I just had a conversation with my boss. I said “Hey, sometimes I can be overly direct and it comes off like an a**hole. I’ve been told I’ve been condescending by co-workers. I’m working on being more empathetic but if you see behavior like this from me, please let me know.”

A few years ago, I wouldn’t have had the confidence to say this. I do this now because I’m aware of my weaknesses and I own them and share them.

This can only help a good manager. (If you don’t have a good manager, then you have bigger problems. I’d start interviewing.) They can help you grow and place you in situations where your strengths can shine and your weaknesses won’t be fatal.

What kind of skills might you have weakness in? There are two dimensions to think about:

  • innate <-> malleable
    • Is the weakness innate in who you are (you are not tall enough to play professional basketball) or how you define yourself (you are simply not interested in learning enough about good design to become a designer), or is it learnable (you want to learn how to write code)?
    • Far more things are learnable than we give ourselves credit for, it is most often a matter of energy and time. That said, as you get on in your career, some weaknesses may be not worth the effort to remediate. I don’t care enough about pixel placement to ever be a designer, which puts certain developer jobs off limits for me. But I have tried the proverbial full stack position a number of times. Don’t write off something until you’ve tried it.
    • The more innate your weakness in a skill required for a job, the more proactive you should be in dealing with the weakness. This includes, as I did, informing your manager of your weakness and then doing some self work to determine how to improve (or if you even want to).
  • core to your job <-> ancillary to your job
    • Is the skill you are weak in important to your job (are you supposed to be able to speak in front of people professionally and yet you have stage fright) or related but not crucial (you need to know a certain technology and you are not conversant with it, but are familiar with the domain space and have learned similar things before).
    • The more core this skill is to your job the more proactive you should be in fixing your weakness–either finding a way to improve or finding a way to shift jobs.

When should you have this conversation about weakness? Not in the job interview. In the job interview you should be trying to put your best foot forward (and evaluating the job), not talking about your weaknesses. However you should consider how your weaknesses might play in to your ability to succeed in your job, which might cause you to pause in taking it.

Also, do not do this in your performance review. That should be about putting your best foot forward to move forward on your career goals (title, money, position, opportunity) as best as you can. (If you have had the conversations previously and have remediated some of the issues, that’s a fine topic to discuss because it shows growth.)

I think the best time to have the conversation about your weaknesses with your manager is after:

  • you have a clear idea about your weaknesses
  • you know how they will affect or not affect your ability to perform in the job
  • you have a plan to ameliorate their effects if they will cause performance issues
  • you have been on the job at least a month or two, and have some wins (because you overindexed)
  • you trust your manager

If all of these are true, then you will be in a good position to frankly discuss the weakness and take steps to minimize the impact. It’s best to do this in a face to face conversation.

If you can’t do this with your manager, at the least have this conversation with yourself. On paper or while exercising or commuting, think through your weaknesses and how they apply to your current position. You may find that your current position is absolutely suited to you, in which case, congratulations. You may find an area to work on or improve (“man, I really need to get better at listening before I talk”), in which case, congratulations. You may find that your current job is perversely lined up with your weaknesses, in which case, take a look around.

Sincerely,

Dan

 

A Crash Course for Your First Job in Software

Dear new developer,

This post, “They Didn’t Teach Us This” is a great read.

There’s a curious phenomenon that happens when new web developers take their first job. You’ve just gotten your CS degree or graduated from bootcamp, and you’ve spent months or years learning to write efficient code, practicing for interviews, and building portfolio projects. Finally you’ve accepted an offer, and you’re thrilled⁠—you’re now a Software Engineer™. You march in on your first day, your head held high. And then, in your first week of work, it dawns on you just how little you actually know.

To be honest, that is what this whole blog is about.

But never fear, the author has some suggestions. There are a whole number of items that matter for professional code (like accessibility, scale, and reliability) that don’t really factor into personal projects. He outlines these and a few other concerns. The author also talks about process (with git, environments and deployments, among other things):

So, what exactly happens during a deploy? To start, you’ve been working in a local “development” environment, which gives you the ability to see changes nearly instantly. However, what gets deployed to production often aren’t the exact files you work with on your local machine.

I didn’t have much process when I was starting out as a new developer, but the older I get, the more process matters to me, even when I am the only developer. It takes the complex and layers an abstraction over it, making it easier. In a very real way, the actual content of a process matters less than that all parties agree to it.

The whole article is worth a read.

Sincerely,

Dan

How to start blogging

Dear new developer,

I was asked about how to start blogging during the Q&A portion of a talk I gave. I had offhandedly recommended blogging as a great way to make connections and to be both credible and findable (locatable?) when looking for a job.

I started to spout off an answer using WordPress, and the questioner said “what about medium?”. And I stopped short. The correct answer is was “whatever is easiest”. I realized that this needed a bit more explanation, hence this letter.

So, the first thing to realize is that almost no one will read it, especially at the beginning. Why would you write if no one will read it? Well, to clarify your thought, to provide a written record of what you’ve done, and because, if you keep at it, Google will find it. Google is great at the long tail, so if you write something that is of interest to anyone, eventually people will find it.

Some numbers. This blog had the following stats for the first six months:

  • Sep: 8 posts/5 visitors
  • Oct: 11 posts/20 visitors
  • Nov: 6/15
  • Dec: 9/219
  • Jan: 8/221
  • Feb: 9/223

For the first month, I wrote more posts than visitors! And for the first three months, I had 25 posts and only 40 visitors. If you aren’t ready and willing to commit for a fair bit of time, your blog will become one of those sad blogs that I occasionally run across with three great posts, then one post six months later with the title “I haven’t posted in a while…” and then nothing.

Now, if that’s what you want, that’s ok (everyone can blog for their own reasons) but if you are looking for credibility and locatability, well, that kind of blog accomplishes neither.

So, commit for six months. I do this by:

  • writing out 20-30 titles of blog posts I want to write. If I can’t come up with that many blog post titles, I am not passionate enough about the topic to stick with it. Better to find out before investing the effort.
  • Watch for interesting concepts and mailing myself whenever I have a possible blog post idea. Then I can search my email when I have time to write but no ideas. (You can do the same with a spreadsheet, doc, trello board or whatever. Just capture the inspiration when you can.)
  • Make some posts easy by doing excerpts or commentary (about half of the posts on this blog are excerpts or guest posts).
  • Settle on a consistent schedule. No need to announce it, though. (Some people do it daily, for which I have mad respect.)
  • Write blog posts ahead of time and schedule them out. When the muse is present, it can be easy to jam out a few posts. When the muse is absent, it is a relief to not need write, but still be able to deliver to previously mentioned consistent schedule.
  • Realize that some of the posts will be mediocre. It is embarrassing to put out poor content. Don’t do that, but some posts will be better than others. Volume is key, and the longer you do it, the better the posts will get.

As far as the actual writing tool, use whatever is comfortable and easy. That may be wordpress.com, may be medium, may be netlify + hugo. Whatever it is, don’t let the technology get in the way of the writing. Especially if you are a developer, it can be more fun to be in weeds tweaking your blog deployment pipeline (at least, that’s really fun for me) but that will distract you from the main goal, which is to create good content.

My final tip is to share on online communities. Don’t only share your own work, but definitely share it. Which community? Well, find out where your people are. There are a lot of communities out there, whether tech specific like Hacker News, general purpose and public like Twitter, or focused and private, like the HangOps Slack. (Sharing is how I was able to break through in December above.)

Doesn’t matter what it is, as long as you are engaged in the community and the topic of your blog is of interest to the community. These communities are well aware of the traffic they can bring and are often wary of newcomers. I have gotten a few scoldings when I posted things that I thought were interesting, but were not in line with the community. That’s OK, just accept the community judgement, acknowledge the mistake, and do better.

Blogging is a great way to amplify your voice, display your expertise and share your knowledge. Set yourself up for success when you start one.

Sincerely,

Dan

Learn a Little Network Engineering

This is a guest blog post from Allan Wintersieck. Enjoy.

Dear new developer,

I realize that just trying to learn basic programming principles can feel daunting enough, but if I may, I’d recommend adding one more task to your list: learn a little bit about network engineering.

Networking underpins everything web and app developers do, since almost every web app communicates from the frontend to the backend regularly. Most developers understand the basics of making API calls and how data flows over the internet, but taking a small dive deeper will help you debug issues for years to come.

The goal is to build your underlying knowledge so that when you encounter related issues in the future, you understand enough about how it all works to intelligently tackle the problem. For example: the reason everyone complains about CORS (Cross-Origin Resource Sharing) being confusing is because it doesn’t make sense without first understanding the basic principles of networking and security.

A quick list to get you started:

  1. Read up on the basics of routing. No need to dive into how the protocols work, but understand why it’s set up this way and how internet traffic gets to where it needs to go.
  2. Read the basics of DNS, and understand how a DNS request is resolved.
  3. Read a brief rundown of the OSI model. Focus on understanding one or two examples of things you’ve dealt with in the past that exist at each layer.
  4. Review the difference between TCP/IP and HTTP, and why they exist at different layers in the model.
  5. Read up on the basics of what a “proxy” is.

An overall analogy that I find helpful: networking is like sending mail via the postal service.

  • Routing is the process of putting mail in your mailbox, having a postal worker pick it up, and it eventually reaching its destination.
  • DNS is the process of looking up someone’s mailing address so you can send them mail.
  • The OSI model is a fancy name for making it clear that there’s a lot of details the postal service takes care of for us. Most people understand how addresses and mailboxes work (let’s call that the equivalent to the Application layer), but don’t really understand all the internal details of how the postal service gets your mail to its destination. All those details are the first 6 layers of the model.

With that background knowledge in place, tackle some of these additional questions to lead you to more learning:

  • How do CDNs (Content Delivery Networks) work?
  • What’s the difference between “regular” HTTP and WebSockets?
  • How does SSL (HTTPS vs. HTTP) work, at a high level?
  • What can nginx be used for?

And as a last exercise, sketch out a complete picture of a work app or side project: what DNS calls get made, what servers are involved, are there any proxies, what protocols are in use, what OSI layer those protocols exist on, etc.

I promise that spending the first few years of my career as a network engineer only slightly biases me towards learning this stuff.

Sincerely,
Allan Wintersieck

Allan Wintersieck is the CTO and co-founder of Devetry, a software consultancy in Denver that provides strategic partnership for software architecture and engineering.