Current things on my list to read:

• Salt – Mark Kurlansky
• Free Culture – Lawrence Lessig (reading this again)
• Chivalry – Maurice Hugh Keen
• Medicine’s 10 Greatest Discoveries – Gerald W. Friedland
• Understanding Physics – Isaac Asimov
• QED – Richard Feynman
• Structure and Interpretation of Computer Programs (SICP) – Sussman & Abelson

Current hopeful/wishlist (because it’s heady material):

• The Feynman Lectures on Physics – Richard Feynman

Most of the books above are pretty short reads with the exception of the two physics tomes. I’ll be swearing off fiction till I’ve read these and educated myself better in areas I ought to have more knowledge in.

This past week I’ve gone out of my way to visit some food trucks and farmer’s markets that I don’t typically get a chance to go to. Those included Where Ya At Matt (Creole foodtruck), Maximus/Minimus (Pork truck) and the Queen Anne Farmer’s Market which has Proper British Bacon as a vendor. Of these three delicious sojourns, two were pork-centric, per my pork love affair.

I’ve often wanted to try British Bacon, never realizing that it was so distinctly different from American bacon. American bacon comes from the pig’s belly while British bacon comes from the pig’s back and is far more lean. When fried in a pan, it is similar in flavor/texture to fresh Canadian bacon but the cut of meat is different. Suffice to say, I will be buying much more of it in the future from the convenient deliveries that Proper British Bacon makes to Microsoft campus.

Along with my delicious newly acquired pork product for home, I’ve finally discovered something resembling good BBQ in Seattle. Maximus/Minimus makes an excellent BBQ pork sandwich. The meat is tender and flavorful. The sauce, light while still bold. Most of all, unlike mediocre BBQ establishments, the meat was not drenched in sauce to hide any mistakes made while cooking the meat.

Now I’ll just have to find a way to make these places a regular weekly visit along with Thai Curry Simple…

It’s hard to program when you don’t really know the APIs and if the APIs aren’t designed well they don’t match with the concepts. For example, I’m trying to use an RSS API and it doesn’t match up with the RSS standard, they call <description> “Subtitle”. If it matched, I could just Intellisense my way to victory.

So in the future, I hope C++ Intellisense improves and the API gets designed a little better so that I can Intellisense my way to victory .

I’ve been relearning Forth lately, trying to get a stronger footing in the language and trying to pick up some of the principles so that I can apply them elsewhere in my work at MSFT. I was reading through Leo Brodie’s Thinking Forth and stumbled on this little pearl of a quote from Chuck Moore:

Sometimes the possibilities for simplification aren’t immediately obvious.

There’s this problem of zooming in a digitized graphics display, such as CAD systems. You have a picture on the screen and you want to zoom in on a portion to see the details.

I used to implement it so that you move the cursor to the position of interest, then press a button, and it zooms until you have a window of the desired size. That was the way I’ve always done it. Until I realized that that was stupid. I never needed to zoom with such fine resolution.

So instead of moving the cursor a pixel at a time, I jump the cursor by units of, say, ten. And instead of increasing the size of box, I jump the size of the box. You don’t have a choice of sizes. You zoom by a factor of four. The in-between sizes are not interesting. You can do it as many times as you like.

By quantizing things fairly brutally, you make it easier to work with, more responsive, and simpler.

1. Object-orientation, while useful, does not scale well to the size of the data sets we now work with and try to manipulate. Following closely to the OO mantra and making most everything an object works but becomes unwieldy as you create programs of sufficient size. I cannot say that program size scales linearly with dataset size, but program size does scale in proportion to dataset size AND what you want to do to that data.
2. Functional programming does deal with the complexity of many environments  by pulling program state out of the equation and letting the developer focus on the data. The problem with functional languages is that they often do not convey the meaning of their code quite as clearly as one would hope. It seems to me that many functional languages lead toward writing clever or novel code. In software engineering, clever code is never really as clever as you thought it was.
3. I did not even mention Structured/Procedural programming (i.e. classic Pascal or C) since we have passed the point of those languages being useful with large data sets.

Cook is certainly on to something with a “Smalltalk of Modeling.” I spent most of my college years programming computational models for biologists. In that time, I got a lot of experience trying to build models of large data sets using Java. I would create these complex and mind boggling programs in order to achieve the model constraints we were looking for. This is the single greatest influence for my statement in #1. The rest of the influence comes from experience in designing systems recently. When dealing with large data sets, a model-based approach appears to be a more tenable approach.

In my recent ponderings, I’ve been reading William Cook’s thoughts on a new “Smalltalk of Modeling” which has lead my own thoughts on new languages. Object Orientation has run its course in terms of how far we can take it. Modeling objects interaction scales only about as well as a human’s ability to converse with more than five people at a time. We can learn from our own interactions with others about what the limits are of OO. If a human cannot interact with more than several people at a time, it stands to reason that a developer would have difficulty in reasoning about a system with exceedingly complex object-oriented relationships. We interact with thousands of people through out our lives, being able to recall the details of those interactions is nearly impossible except with the most exceptional interactions. Similarly, “well written” OO programs employ a large number of objects but this also means that once a program reaches a certain critical mass, the interaction of the subsystems becomes unwieldy and difficult to track.

Cook mentions focusing on the forest rather than the trees. My own interpretation of this is that we are approaching a point of needing a new model which can cope with the complexity and enormity of the data sets available to us. Building models of the data and manipulating the models will become the paradigm of programming with the enormous data sets. At least this is the argument Cook makes.

I for one am open to other paradigms. Functional programming offers its own benefits but I am unconvinced that it will gain widespread popularity. Haskell, for example, has a certain elegance but anecdotal evidence has shown that programs written in Haskell never look nearly as clear or elegant as the examples. Perhaps it is my inexperience or the overwhelming amount of developing I have done in C, C++, C#, Java and Python but I just cannot get behind the cleverness of Haskell.

Perhaps Cook is on to something with this “Smalltalk of Modeling”. I will be watching.

• Questions are free. Ask lots of them, people will forgive you if they’re dumb. There’s an impossibly large amount of technology floating around Microsoft and no one can be expected to know it all.
• Whiteboards are awesome. Bored? Draw a picture! Stumped? Write it out, draw pictures, diagram! Can’t keep track of what you need to do? Write it down! I was never big on whiteboards until I got here and seeing as it is hard to huddle around a piece of paper, whiteboards solve the problem.
• Identify the strongest developers and consult them, always. I have always considered myself to be a strong developer given my experience. That said, nothing matches people who have worked with software for 20+ years. They may be set in their ways, but often they have vast quantities of knowledge to share. I spend half my time working out problems with the guys that have been around the block for a while.
• The best SDETs (Software Development Engineer in Test) are the ones who know when to compromise but also know when to not back down. As an SDET, you are the last line of defense for ensuring that the product code is of the quality expected to ship. Correctness is vastly important in software engineering, however even if everyone agrees that the correct solution is X, sometimes the timeline dictates you settle for a lesser solution Y which only solves a subset of the issues. Knowing when to compromise and accept that lesser solution is an important skill to develop, otherwise you’ll never be happy and be continually at odds with your Developers and PMs.
• Speak your mind. If you want people to take you seriously, speak your mind. People are smart at Microsoft, but they are not mind readers. Recognition from your peers comes from making compelling arguments for causes you are passionate about. Even if you are wrong, if you make a well reasoned case for your argument people will respect that.
• Make mistakes. Lots of them. Then learn from them. You will make mistakes, have no doubt about that. What will set you apart from your peers is how quickly and effectively you learn from them.
• Smart objects/pointers are your friends. I spend about 90% of my time writing C++ code. During the year I have had to develop my C++ skills, the single most important concept I have applied on a daily basis is wrapping everything in smart pointers. Most of our debug breaks and nasty bugs come from memory leaks, ref-count errors and unreleased resources (Handles, Critical Sections, etc.). In addition to this, RAII is key when you must allocate and de-allocate resources yourself (e.g. Critical Sections).
• Recognize solutions, not problems. Newer hires tend to identify problems and raise them. This is great but it still does not solve the problem. Experienced engineers tend to identify solutions and act on them. Part of the transition from going from a junior engineer to a senior engineer is learning to identify solutions instead of problems.
• Work on your “soft” skills. Your technical skills will not set you apart at Microsoft. There are far too many smart people at Microsoft in order for you to differentiate yourself as some sort of “Rock Star Programming”. What will set you apart and what makes engineers successful at Microsoft are “soft” skills, also known as people skills. You gain seniority by your ability to convince others that you are correct and to rally them behind your cause. There is no doubt that technical skills play a huge role in advancement, but the differentiator will be your soft skills. Between two engineers with similar technical skill levels, the engineer who will be more effective job is the engineer with the strongest soft skills.

Overall, this is just the short list of things I have learned. The most important skill I learned was the last point, “soft” skills. I am still not great at dealing with people and that is partly due to being an introvert. My first instinct when dealing with conflict and people is to hide. I prefer to solve technical problems, not people problems so my first tendency is to solve any particular problem by going after the technical points and avoiding the people. The biggest problem with this approach is that I tend to identify ways in which I can push through the solution I desire technically and avoid the people. In other words, I tended toward the “it is better to ask for forgiveness than permission” approach.

In the end, the points I outlined above apply in nearly all settings as an engineer (software or not). These are by no means Microsoft isolated, however every company has its own culture so some of the more social aspects of the points above may need massaging to fit the company you work for. My only other point of reference is my time spent at Google and my impression is that the same principles apply. The technical points though are applicable in all cases and should have no exceptions.

Ultimately I would like to write this sort of post about once a year to contemplate what I need to work on as an engineer as my career progresses with Microsoft. Despite the hemorrhaging of talent from Microsoft to Google to Amazon to Facebook and back, I see myself staying with Microsoft for a while. While Amazon has established itself in the market, I am unconvinced that Google or Facebook will continue to keep their edge. Microsoft has its quirks but I think any successful company does and Microsoft has made some significant changes internally that I feel show a change for the better.

I have worked long enough now as a professional developer to have developed some insight into the Wild West of an industry I work in. In short that means I have seen a few battles and have some war stories and insight to share now that I did not when I started the old blog. I have also learnt a great deal more about what software development is all about (hint: It has very little to do with technical skill after a certain point). Expect to see some writings on C++, Erlang and perhaps a bit of Ruby as well as general musings regarding my efforts to become a senior software engineer at Microsoft.

In addition to the programming related writings, I will also be renewing my attempts at recording my cooking experiments. I think the first of these will be a short post on the Green Curry with Fish and Sunflower Seed Butter that I made last week. Sounds strange, turned out quite fantastic.

Perhaps after some time I will start sharing the posts with regularity on those absurd “aggregator” sites like Reddit and Hacker News. I think I will first stretch out what rusty skills I have as a writer and only spam my Twitter audience.