I've been in the software business since before it was called the software business and sometimes it can be a cold and hard place. We in technology frequently lose sight of the fact that we are people just trying to solve problems for other people. We talk about resources and levels of effort when we really mean dedicated people and hard work. We go on and on about features and bug fixes instead of time saved and frustrations eliminated.
Getting Clojure!
I'm thrilled to announce that my latest book Getting Clojure, is out in beta and that the first edition will be out shortly.
Getting Clojure takes an idea based approach to teaching functional programming and Clojure. Each chapter of Getting Clojure takes a feature or two or three from the language, explains the syntax and the mechanics behind that feature so that you can make it work before digging into the deeper questions: What's the thinking behind the feature? And how does it fit in with the rest of the language?
Getting Clojure also includes two features that worked so well in my previous books: Every chapter includes a In the Wild section that shows how the programming concepts and features covered in the chapter are used in real world code. Each chapter also includes a Staying Out of Trouble section that points out how you might go wrong using this feature.
Getting Clojure is aimed that programmers who have some experience with other programming languages but who are new to Clojure. The book is also for you if you have been using Clojure for awhile but don't really have a handle on what is going on behind the scenes.
Explaining
One of the things that I think a lot about is explaining technical things. In fact, having just finished Getting Clojure, I've spend the last year or so thinking about very little else.
But it's not just authors who have to wrangle with explaining. Have you ever thought about how much of software engineering involves explaining things? We stick comments in our program to explain why we added X to Y, we type up README files to explain the program, we write proposals to explain why the program should be funded and we spend the afternoon explaining the whole thing to the new developer so that we can move on to something new.
A decent explanation can be the difference between success and the trash bin: Have you ever thrown an otherwise working bit of software away because you needed to fix a bug or make an enhancement but nobody knew how it worked? I have.
Fortunately explaining is something that everyone can learn. Here's how:
Be sure to check back because this series or articles -- like explaining itself -- is a work in progress.
People
One of the joys of being in the software business is the number and range (yes, that's the word) of people you meet along the way. Here is a miscellaneous collection of articles about the people I've come across in my adventures:
Programming
And I do occasionally thing about the technology that drives this all forward:
Books
And I also read alot:
Conference Speaking
Speaking at technical conferences is a gift that keeps on giving. A looming technical talk is one of the best motivators for learning some topic inside and out. Speaking at a conference means that you are seen as an expert and you get to meet all sort of interesting, like-minded people. And sometimes there's cupcakes.
But preparing for and delivering a good technical talk is not something that just happens. Read here how you can make it happen:
Finally, you can find a more taditional more traditional most recent article first view here.
