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

The Cacophony of the 2019 Tech Landscape

This is a guest post from Rishi Malik. Enjoy.

Hello New Developer!

Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.

2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.

What I mean, is that you’ll find points of view on everything. Developers have always loved flame wars, and pointless battles (vi vs emacs, tabs vs spaces). Now it’s “Javascript developers aren’t real engineers”, or “If you can’t code a binary search, you’re a bad engineer.”

Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.

To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.

It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.

On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.

This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.

The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.

Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.

But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.

Good luck, and have fun!

Rishi

Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.

Learn your standard library

Dear new developer,

If you want to be good at interviews, learn your algorithms. Loads of companies treat algorithm knowledge as a proxy for general problem solving ability. It makes a certain sort of sense–you have to break down a problem into pieces, turn it into something software can digest, and implement it in code. You can practice these at places like HackerRank. Like any proxy, they can be gamed, which is why tech interviewing feels like a fundamentally broken process. (See this great post about humility in interviewers for another piece of the puzzle.)

But if you want to be good at your job, learn your standard library. This is the piece of software that surrounds you, in which your software will execute.

I remember the time when I was a contractor and started at a new place in the early 2000s. Someone there had written their own connection pooling library. This seemed like madness because it’s a complicated piece of work and there were several free implementations available for the language (though, to be fair, none were part of the standard library). This code, which provided very little business value, would have to be maintained and bugfixed and upgraded.

Every modern language has a definition (this includes syntax and keywords) and a set of associated, standardized classes. These classes allow developers to “stand on the shoulders of giants” and should be used whenever possible. Why? These libraries evolve over time as the language is released and have a number of beneficial properties.

  • Using the standard library lets you accelerate development. You don’t have to roll your own hash or tree, you can just use the one that ships with your library.
  • It is far more likely to be correct. This can matter a little, if incorrectness introduces a bug. Or it can matter a lot, if incorrectness causes your system to be fundamentally insecure. Standard libraries have a lot of eyes on them, including specialists.
  • As a corollary, standard libraries handle edge cases. They are well used code, in the sense of this post (source code doesn’t rust). If the language is used by any number of people, it’s going to be more bullet proof and handle weird edge cases that your self rolled code won’t handle (until a bug is discovered and fixed).
  • It will be more performant. Again, this is because the effort to make operations faster is amortized across all of the users, so specialists and experts are more likely to be involved.
  • The standard library for any popular language will be maintained over years, likely by developers you won’t have to directly pay.

All of these benefits stem from the fact that more people work on standard libraries than work on code in your company.

But, you have to know the standard library to gain all of these advantages. Unlike the syntax of a language, you don’t need to know the standard library to get things done. While you can’t roll up your sleeves and start coding until you know the syntax of ruby, php, java, clojure, haskell, javascript, etc, you can code for quite some time without knowing all the ins and outs of the standard library.

This is because standard libraries can be large: Java has thousands of classes in their standard library, and even a language with a small library like Javascript has about seventy objects, many with tens of properties or methods. It takes a while to learn. Plus, new developer, it can feel like you’re not doing much when you are reading docs. Certainly such reading  isn’t as fun as banging out code. But, it will have two benefits for the codebase:

  • you will save time in developing because of all the benefits above. You may have to invest some time up front, but once you do, you’ll be faster for the rest of your career.
  • you will write idiomatic code. Other developers who are familiar with the standard library will know the characteristics and behavior of the code you write.

and one for you:

  • you will gain a transferable skillset. Learning how to write the particular kind of ruby that your company uses is not nearly so valuable to other companies as learning the standard library.

How can you learn the standard library? I’d recommend taking a high level overflight. Google for ‘<language> standard library overview’ and read whatever articles or listen to whatever presentations are available. I’d also recommend just scanning the docs and seeing what piques your interest.

After you have that, the best way to learn the standard library is to use it. When you are about to tackle a problem, make it a standard part of your process to ask “is there a standard library function for that”. It can be difficult, but as it becomes a habit your code will become better and you will learn to trust the authors of the standard library.

If you have time and inclination, you can also search for ‘<language> koans’ which are small exercises in languages. These will often exercise the standard library. See Ruby Koans for an example.

When there is more than one way to do it using the standard library, which happens more in some languages (like PHP) than in others (like golang), think about the options and then try to be consistent.

So, learn the standard library. Make the time.

Sincerely,

Dan

Avoid The Impossible Goal of Being a Know It All

This is a guest blog post from Rick Manelius. Enjoy.

Dear new developer,

Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?

Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.

A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials.  Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.

I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.

Years later, I discovered this humbling infographic titled Becoming a Web Developer in 2017. I love this because it highlights the absurdity in trying to learn everything about everything in the web dev ecosystem. While all sites eventually roll up to HTML, CSS, and JavaScript, the number of underlying technologies used to support them is visually overwhelming.

68747470733a2f2f692e696d6775722e636f6d2f4d576b654d31382e706e67
A select infographic from The Web Developer Roadmap 2017

Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.

Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.

To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.

Before I overwhelm you any further…

…there is hope.

You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.

Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.

The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.

Adopt a Hive Mind Approach

We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.

By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.

So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.

Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.

So get out there! And good luck!

– Rick

Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.

Tips for Building Your Work Network

Dear new developer,

I talked previously about a technique to help you network with strangers.

But networking isn’t just about meeting strangers and starting up conversations easily. The easiest way to build your network is to foster it at work. Again, this will help you if you are looking to hire, learn more about an interesting company for a job or partnership, or want to ask someone about technology they’ve used or problems they’ve faced.

Here are some tips that will help you do so.

  • Use LinkedIn. I’ve already written about that, so I’ll just say that you should keep your profile up to date with your positions and accomplishments, as well as link to folks you have met in a professional context.
  • Never leave a job on bad terms. This means giving the requisite notice, running through the finish line by documenting your work and preparing for a handoff, and not speaking ill of your former employer (of course, I am not a lawyer and there are definitely grounds for speaking ill of your employer if they’ve violated laws). You may be very excited about the new job, but think about how you’re leaving your current position, and treat your teammates as you’d want to be treated. Doing so means that when you want to tap your network, they’ll respond.
  • Reach out periodically. This can be as simple as sending them a LinkedIn note when they have a work anniversary or have changed jobs. If you know they are interested in a technology or domain and have run across an interesting article (perhaps via your RSS feed or your online community) send it to them with a quick note. If you are going to be in the town where they live, suggest meeting up for a coffee to catch up.
  • If someone has a request for their network, try to help. Depending on how strong your relationship, you may want to reshare the request, think of someone who could help, or attempt to help yourself. Be wary of doing too much for the strength of the relationship. I was overly enthusiastic once and sent a bunch of intro emails for a new service an acquaintance was starting. The service didn’t go anywhere and I felt foolish for asking people I was relatively weakly connected to for their help.
  • If you ask for help, follow up if someone provides it. Thank them and let them know how you used their help. Nothing is less fun than helping someone in any way and then having them go dark on you. And don’t ask for help too often from the same person–this is more qualitative and you have to judge the strength of the relationship; the stronger the relationship, the more often you can ask.

I’ve used these tips in the past to keep my network alive and will do so in the future. Unlike in other professions, the bar for network activity in development is very low, so if you do even one of these, you’ll likely stand out.

Sincerely,

Dan

Tips from a recent bootcamp graduate

This is a guest blog post from Jesse Ling. Enjoy.

Dear new developer,

Be comfortable with being uncomfortable. You’ll never know all the things. And that’s ok.

Ask questions – at the right time. There’s a fine line between reaching out for help too early and too late. Struggling is imperative to growth, but reaching out for answers too soon significantly hinders it. You’ll better understand where that line lives over time.

“Stand on the shoulders of giants.” More than likely, your problem has already been solved. Don’t be afraid of trying other’s solutions if it makes sense for your implementation. But do take the time to fully understand why and how it works.

Be persistent. Programming is difficult and often times frustrating. Don’t give up. The feeling of figuring things out after a struggle is amazing.

Network. Talk to devs at, below, and above your skill level. Opportunities can present themselves in mysterious ways. Utilize your network to not only help yourself, but more importantly to help others.

Sincerely,

Jesse Ling

Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.