Introduction
The aim of this book is to teach software development by example. Rather than canned examples with predetermined teaching goals and known solutions; it documents programming episodes, with real-world uncertainties, blind-alleys, short-cuts and failures.
This is not a book to teach you how to program. It assumes that you have already mastered the basics, consider yourself an accomplished programmer even, but want to improve. You have a good grounding in a modern programming language, but are aware that there are techniques and mindsets that you have yet to experience. Like me you realise that, however big a fish you are, you have so far been swimming in a small pond.
This is not a book about Kotlin. The examples are in Kotlin because I believe that the language strikes a good balance between easy readability and being expressive enough. Before Kotlin I might have chosen Python, but my preferences are strongly-typed, especially where I need to communicate with other programmers or my future self. My aim is to explain those features of the language that might not be obvious to most programmers, but, at the time of writing, I’m aware that I haven’t addressed this at all.
What this book is, I hope, is a guide to the path from journeyman to master, from programmer to all-round developer. It covers not only the act of writing, testing and refactoring code but also the process of deciding what should be written, how to strike a balance between adding functionality and improving what we have, how to assess and manage risk and costs, and how to maintain a good relationship with our customers. It is, in short, a book about engineering.
While lots of books cover this material, and I recommend some of them in the text, it’s hard to find one that covers all these topics in the optimum depth. My approach to deciding what to cover is simple, start work on non-trivial software development, see what crops up, and talk about it as if we’re pair programming and you’re interested in what I have to say. If this is a good approach, everything important will be addressed, and really important things will be covered from several angles. Otherwise I may have to invent problems to illustrate an important topic, or shoehorn a discussion into an inappropriate gap. See if you can spot these happening!
As far as I can muster the energy to do so, I have tried to document things as they actually happened. There are times when I have expurgated some tedious details in order to keep you reading, but I have not returned to an example to paint it in a better, or worse, light than live. Post-production has been limited to formatting, copy-editing and conclusion-drawing; no scenes were filmed out of order or staged for entertainment value.
To keep me honest, you can see the history of this book in its GitHub repository. That would also be a great place to submit any corrections, suggestions or feedback.
Request for Feedback
If you’ve got this far through the introduction, I hope that I have at least piqued your interest. Even if I haven’t though, can I ask you to give me some feedback?
If this section is still in the book it is still some way from being completed. Honestly, I don’t know how it is working out. I’m really enjoying writing it, some people have said that they enjoyed reading it, but whether it is adding value to the world, and whether the format and topic stand a chance of meeting their aims, are still up for grabs.
If the book does interest you, and you reach the end of Chapter One and still have any will to live left, please follow the instructions there to send me feedback.
If you’ve decided on the text so far that the book isn’t for you, but can spare me 2 more minutes of your time, then please follow the instructions below.
Thank you
Duncan
Please create an email to me, copy the following into an email, start answering at the top, keep going until you don’t think you owe me any more or your precious time, and send. I’m sorry that I don’t have an embedded form or anything - yet. Maybe if there is enough encouragement the processing of the form will become a chapter!
- Should I continue writing this book? [y | n]
- Are you in the book’s target market (3 - 10+ years of programming experience)? [y | n]
- What do you think of the recursive nature of the material, writing about the development of the software to assist the writing? [0 (disaster) - 10 (triumph)]
- How likely are you to recommend the book to a friend or colleague? [0 - 10]
- Would you pay to read the completed book? [y | n]
- Do you care about paper copies of books? [y | n]
- Is there anything else you’d like to say? [ ... ]