Sometimes you just have to ship it

Dear new developer,

For me, there comes a point at the end of every project where I’m just sick of it. I’m sick of the project. I’m sick of the technology. I’m sick of project management system. I’m sick of the code.

Sometimes, I just want to see the whole thing burn. Or better, just ship it.

Now, I think that there are two solutions to this problem, and which one you pick depends on your timeline. The first is to take a step back. Talk to a team mate. Work on something else. Talk a walk. Take an extra half hour for lunch.

This may give you perspective to help you dive back in and add just a bit more polish. That polish, which may take the form of additional UX refinement, testing, or even wordsmithing the help messages or marketing text, can help make the project shine.

That’s what I call ‘running through the finish line’ where you want to leave it all on the field. That doesn’t mean you don’t make compromises or that you won’t revisit decisions, but it does mean that you do the best you can. Sometimes to put in that final effort, you need to take a break.

The other choice is to just ship it. This is a good option when you are up against a deadline. It also helps if you know you are a perfectionist and/or afraid of putting your work out there. Nothing is perfect and if your work never sees the light of day because you can’t accept that, the world is losing out (as are you). Finally, it can help if you take that time off, acquire that perspective and know that you’re done with this phase of the work.

I just published a book. It was released on Aug 16. I’m very proud of it, but there were times when I was just plain sick of it. I ended up taking some time away from it and that helped me make sure it was the best book it could be.

When you are working through the final bits of a project, sit back and get that perspective. And then, ship it!

Sincerely,

Dan

Make it work

This is a guest post from Tim Bourguignon. Enjoy.

Dear new developer,

Let me tell you a story.

Once upon a time, there was a black chalk board in a dark room. The board carried remainders of countless creations. Diagrams that could pass as hieroglyphs for the non-educated eye. Or well crafted UML to the others. From systems to modules, modules to components and component to classes, it all seemed to flow. Generic, inter-operable and reusable, it was beautiful. Those architectural blueprints led the creation of the software. Countless tests secured it, using the best means at hand. Production servers welcomed the bits. But a few week later, the company shut down. There was no market for this software. There was not enough cash left for the company to pivot and explore a different idea. Too much time was lost writing the most beautiful and never used piece of code in the world. Beautiful or well crafted code that doesn’t solve a real problem doesn’t count.

Once upon another time, a software crashed in production. A website was down. A shopping system was not taking orders. A customer was losing a fair amount of money for every hour, every minute and every second that passed. And boy was she furious. A few caffeine-doped hacking hours solved the problem. Thankfulness replaced the customer’s furor. The architecture of the solution lacked flexibility. The re-use potential was at an ever lowest. A bitter smell of copy-paste still held in the air. And the amount of technical debt in the codebase reached new heights. But the fix saved the business. Sometimes, ugly or imperfect code that “do the job” is the best you can hope for.

Here’s how David Heinemeier Hanson and Jason Fried described the launch of Basecamp:

When we launched Basecamp, we didn’t even have the ability to bill customers! Because the product billed in monthly cycles, we knew we had a thirty-day gap to figure it out. So we used the time before launch to solve more urgent problems that actually mattered on day one. Day 30 could wait.

Rework by DHH & Jason Fried

Let me rephrase this: they launched a paid-product with no way to earn money! Does this sound sane to you? It actually is. Worst case scenario, nobody is willing to pay anyway. They don’t have users, they don’t need a payment system. Period. They concentrated their effort on making a great product until the launch date. If the product attracted customers, they would need a payment system. The month that ensued might have been smooth… or very bumpy. Again at the end of that following month, some code had to be running. Good or bad, perfect or crappy looking, it had to do the job. Otherwise they would lose money.

Let’s generalize by putting code aside for a moment. Have you ever written a text to throw it out seconds later realizing how crappy it was? I know I do it countless times every single day. Have you ever had a great idea put you into ecstasy, only to throw it away the moment you put it on paper. Have you ever realized how dumb an idea you had, after hearing you verbalize it? I know I do every single day. Plans are perfect, until they meet reality.

For everything you do, there is a right time. Sometimes it is “yesterday”, sometimes it is “now”. But more often than not, it is “later” or even “never”. The best way to find it out is to strive to make “it” work. Whatever you do, try to make your plans meet reality as fast as possible. Only then can you be sure you are not working on false promises.

Don’t underestimate this first rule. We often forget about it at the first pinch of peer pressure. If you write software as part of a team, you have experienced a variation of the following in the past:

My coworkers will review my code. What will they think of me? I’d better refactor this component, make non-trivial changes to this module, enable future extensions in this class and clean my code up to its core to uphold the design standards…

What I could have done in a few minutes has grown into hours and the peer pressure increases. What has taken a long time to craft must be excellent, or was it the contrary?

Can you live up to this first rule? Our formal education taught us to seek the unattainable best grade and to hunt for any flaws. To the contrary, this rule tells us to seek the “good-enough” and then iterate on it. Use those intermediate versions to foster discussion. Lay a “good-enough” version of your work on the table, be open about its flaws and be sharp in criticizing it yourself. As a group, you can then decide whether to invest in making it suck less, or leave it be. As J.B. Rainsberger said in his talk “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development”:

If every item in our shop either costs $8 or $13 and we hard-coded those values, we are done!

Of course, not every draft that does the job is production ready. Production is often far away down the road. You will have to work hard to find out what “good-enough” means for every new challenge you face. But by seeking working solutions in your daily life, you will make true progress. Refine working software. Keep both feet on the ground and focus on tiny measured steps. This is the basis for producing a good solution. The solution that is there when the deadline falls. The solution that makes the business work.

— Tim

This post was originally published at Auswanderer Quatsch ².

Tim has been building synapses between human beings since 1983. Passionate developer, Mentoring advocate, mentor and mentee himself, he works as Chief Learning Officer, Head of Agile and technical Agile Coach for the MATHEMA company in Germany. In his free time, he hosts the Software Developer’s Journey podcast and spends as much time as he can with his wife, with [1;3] kids clutched on his back!

“Letters To a New Developer”, the book

Dear new developer,

I hope you enjoyed reading these letters. I’ve certain enjoyed writing them. When I chat with new developers, at meetups, on slack, or via email, they let me know when letters are helpful or unclear. They suggest topics. They give me feedback, which, when you’re writing into the howling abyss of the internet, is very helpful both for calibrating your message and improving your motivation.

I’ve also posted these letters to some online communities. I’ve received plenty of feedback from those folks as well. Some kind, some caustic. That’s not unexpected.

After writing a hundred or so posts, I thought, there’s a book here.

And so I wrote one.

You can buy it from any of the usual suspects:

You can also check out a preview of the chapters on the publisher’s website. I’d love if you’d do so.

Here’s who I wrote it for:

For new developers
You are new to the software development job market. Perhaps you have completed a bootcamp or college degree. You may refer to yourself as an entry level or junior engineer.

While everyone’s background and skills growth happens at different speeds, new developers generally have less than five years of professional experience. Many new developers are worried about their abilities, don’t feel welcome, and have a difficult time finding that first job.

But as an industry, we need more new developers. There are so many problems with which software can help. Companies want experienced engineers, but all the senior developers I know started out as new developers. A senior engineer is just a new engineer seasoned with gaffes, education, and time.

For new developers, this book will help you avoid missteps I’ve made. It also introduces you to disciplines beyond coding critical to success. While programming is crucial for any software product or service, there is much more required to deliver an application.

For anyone considering software development
If you’re not sure if software engineering is right for you, this book offers perspectives on how to succeed.

I’ve intentionally kept the barriers to the layperson low with limited technical jargon. Only a few technologies are discussed, and those sections can be skipped. If you are thinking about becoming a developer, I’d recommend buying this book and a book about programming.

Giving a computer commands that it can execute is an important skill for any software developer. But software engineering is so much more. You must know what to build, how to work with your team, and how to maintain your systems.

For mentors
If you are mentoring a new developer, this book can serve as a discussion guide. Because each chapter has letters approaching a theme from different angles, you and your mentee will find it useful for focused mentoring sessions.

As an experienced developer, you’ll of course bring your own insights and experience to each topic, from your debugging process to the value of an online community for continuous learning.

And, of course, you may have had a different experience than what I share. Such contrasts are a jumping-off point to discuss the diversity available in a software development career.

Introduction, “Letters To a New Developer”

Sincerely,

Dan

I’m writing the book I wished I’d read

Dear new developers,

Update July 5, 2020: I now have a launch date and a cover.

You may have noticed the pace of new letters has slowed down a bit. There have been some fantastic guest posts, but there’s only been one new letter per week for a while. There’s a reason for that.

I’m excited to announce that I’m writing a book. It’s the book I wished I’d had when I was beginning my development career.

It’s based on this blog, with ideas, text and guest posts drawn from it. The format is similar: letters covering a variety of topics. However, all the content has been thoroughly reviewed, organized and revised. You’ll also see new letters covering topics left untouched by this blog.

I just shipped off the first half of the book to the publisher. If you want to be in the loop, contact me to be put on the book announcement list.

– Dan

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

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