Category Archives: Business

Manager Who Codes vs Developer Team Lead

Personal branding is deceptively effective in many cases.

The difference is skills between a manager who codes and a developer team lead is negligible.  In many cases you could say they are job titles that describe the same role in a company and yet from a HR and status point of view they are very different.

If you’re getting hired into a position having presented yourself as management material with the bonus of having technical skills then you get lobbed easy questions in a relaxed setting (usually).  The hiring decision is based more on fuzzy “I liked her” type of gut reactions than any type of objective assessment of skills.  With this initial staging you are more likely to be treated as an equal with other “higher status” management employees.  And any technical skills you have will be treated as a bonus.

Brand yourself as a developer with team lead experience and you will get a barrage of technical questions.  A high stress examination of how well you know obscure algorithms, or specific programming language APIs. In this case any holes in your knowledge will be assessed as negatives.

The difference in hiring practices between these two roles is night and day.

With this admittedly specific and anecdotal comparison it would be interesting to see just how real and widespread this effect can be.

In my experience there seems to be a causal relation between what you internally believe your self worth to be, and the employment positions you get.  A strong personal brand comes out naturally when you have the confidence to tackle a “higher status” role.

If there’s a lesson here it’s this:

Position yourself for the future you want to have and there’s a better chance you’ll get it.


The term Service Oriented Architecture has been twisted by so many people now that it has lost some of it’s meaning. Microservices is a software architecture for web apps that aims to define a more specific way of doing SOA that isn’t so fuzzy and hand wavy.

Web applications have long been developed in a SOA way.  Especially with the advent of PaaSes like Heroku which make it easy to bolt on services.  But even when building an app to run on Heroku it’s easy to create a monolithic application which may better be segmented into separate services.

By dividing your application into micro services you can focus on clear contracts and well defined APIs. If you have an application that can be divided between people to work on then micro services allow you to reduce the cognitive burden of understanding the entire application.  It makes regression errors less likely, and gives you the focus to produce a high quality service.

You can go pretty far with micro services.

Exactly how micro you go can depend on your goals and the size/requirements of your project.

A project I’m working on now will be creating a separate analytics service.  By pulling this API into a distinct application we were able to choose a different technology stack that  was better suited to the requirements.  For uptime and performance it made sense to write the analytics API in Go, this provides nearly 10x the performance of our usual Rails stack.  Given that we expect the reporting app (in Rails) to be updated far more often than the analytics gathering API it’s valuable to isolate it.

This separation is just the start. In a micro service architected system you can go so far as to pull out user accounts, generating reports, sending reports, processing various things etc. all into their own stand alone service.  Then tie everything together with asynchronous message bus so that if a service goes down messages are queued and nothing gets lost.

There are some performance issues to be aware of.  A request going through a message bus adds significantly more overhead compared to a function call.  As a result some thought should be made on how to design the API with some performance considerations. Perhaps adding a bulk update operation as an example.

The benefits to pulling off a successful micro service architecture can be huge for managing the scalability of a big system.  If you have a project that is going to be big enough to require 4-5+ full time developers then consider micro services so that you can divide the work into multiple stand alone micro services.

Time Audit Surprise

When you measure things you can manage them – Words of wisdom from Peter Drucker.

Every time I have made the effort to measure something whether it be calories, carbs, miles run, heart rate, cash flow, net worth or weight there is always a surprise in what the numbers reveal. Recently I did a one week time audit; writing everything I did to the nearest 30 minute interval.

Prior to actually measuring things I would be swayed by my perceptive bias.  Things that I don’t like doing would seem to take more time than they actually did, and those things that I enjoy would take more time, and seem like less.  This emotional influence on time perception can deceive you into making poor time management choices.

Sleep was the biggest single bucket for spending my time.  it consumed 33% of the week.  That is a lot of time I wish I could take better advantage of.  There are other animals in the world that sleep far less often than us humans so perhaps there are some (yet undiscovered) ways to sustainably reduce our sleep requirements.  Until then sleeping will continue to be a big part of life.

Employment was the second biggest time  consumer. 23% of the week was spent in full-time employment.  An additional 3% was spent commuting to and from work so a total of 26% of my time went towards earning a pay check.

11.5% was family time.  Taking care of a 8 month old can take as much time as I have to give.  It certainly didn’t feel like I was getting this much family time.

10% of my time was spent on preparing or eating food.  For me that was a shocking number since I usually have a handful of something quick for breakfast and skip lunch.  Cooking and eating supper was taking a lot more time than I had realized.

Time dedicated to personal projects on the computer was just 5.5% of my time.  Not enough to make progress and much less than I wanted to  spend on it.

Rounding out the last few things that took time,  Reading, shopping and housework consumed 3% of my time each and TV was at 2%.

There are a fixed number of hours in the week (168).  Getting more time to work on my side projects requires taking hours away from something else.  Deciding what to cut is difficult, actually figuring out the logistics to cut out that time is also difficult.  Hours are not easy to re-allocate without major life changes and stressing other things and so it will be a struggle to adjust to a new schedule.

Change is hard.  Changing how your spend your time, can actually change who you are which can be fundamentally difficult to drive from yourself without an external influence (like having a child).

This time audit raised some interesting issues. Time is our most valuable resource and yet so few of us understand how to best utilize  the time we have given to us.  A disconnect between your goals and your time  can be a critical underlying issue that prevents your success.  I would encourage everyone to do a time audit.  You may find it as surprising as I did.

Applying The Creative Writing Process to Software

Grabbing the best ideas from other industries and applying it to your own is a fantastic way to learn and discover new ways to do things.

I was listening to the Tim Ferriss podcast yesterday in an interview with Neil Strauss.  Two best selling authors discussing their creative process for writing a book.  It got me thinking if some of the approaches they discuss could apply to to software development -which is also a highly creative process.

Let’s break down Neil’s process a bit.

The first part is to do a lot of research.  For example, when Neil is doing an interview with a celebrity, he will read everything they’ve written, listen to ever song, devour every bit of information he can about the person.  He writes out a list of 100 questions for the person and studies it like you would for exam prep.  Finally when it’s time for the interview he puts the questions in his back pocket and forgets about them.  As a result of this level of preparation and study the interviews can flow naturally.  He has a backup of questions to draw on if the conversation stalls but usually he can riff off the bulk of knowlege he has collected to build rapport and get to the really interesting details.

With a cache of notes from research it’s time to start writing.  There will be several drafts and the goal of the first one is to “Write to the end”.  Convert the pile of notes into a story as quickly and rough as possible without self editing along the way until you get to the end of the book.  This first draft will be read by no body else.

After the first draft you are just 1/4 the way finished.  The second draft is done for the readers.  You cut out all the uninteresting pieces, ensure the story arc is solid, characters are developed enough, flow is good, and jokes are funny.  You do this by putting on the hat of a reader and ruthlessly editing your first draft.

The next step is to put on the hat of a hater.  To deflect criticism before it happens you go through it again with the perspective of someone who wants to debunk your stuff and criticize your ideas.  At this step you fact check everything, and make sure there’s nothing offensive, or at least that the counter points are acknowledged and dealt with.

Finally it goes to the editor and is test read by anyone who wants to read the manuscript. Listen to their criticism, and adjust your book to improve things and cut parts that people don’t find interesting.

After enough feedback you’ll know when to lock down the book to a final version and send it to be published.

For an average size book this whole process can take upwards of a year to complete.

There are some lessons that we can take from the best approaches to writing books and apply it to writing software.

Notice that this approach to writing a book is not Agile, and it’s not waterfall, it doesn’t involve sprints, scrums or user stories. It’s completely unique to the way most software is created.

The first part of Neil’s process is research.  You might roughly correlate this step to requirements gathering but that vastly understates the effort Neil goes through.  I have never met a developer that thoroughly masters the domain knowledge before typing anything the way Neil does.  Taking months and often years to interview people, take courses, and generally immerse yourself in the space you will eventually write about gives you skills and knowledge to be able to write “to the end” without pause.

Side note: Interruption is one of the most detrimental things to the creative process. Stopping to look something up, or ask a question of the client can waste half a day of productivity.  Agile methods promote this open communication during development… maybe there’s a better way.

Writing to the end for the first draft is something not possible without having enough domain knowledge to do it in the first place..  There really isn’t a comparable product in any software project I have personally worked on which compares to this first draft.  The scope of Neil’s first draft expands far beyond what is in the final book as he will likely cut 50% of the pages during editing.  It has me wondering if it would be a good software development approach to rip through a 20,000 line first cut of an application knowing that I’d delete 1/2 of the code before being finished, slashing out features along the way.

If we did write this quick rough first draft application with the intention of whittling away anything superfluous to arrive ultimately at a publishable product then the next step would be to put on the hat of someone who wants or needs to use this software. Can you make the interface more intuitive? Can you give it some life? Are there any features that are more complex than they’re worth? What can be cut without destroying the utility of the application?

It would be only after these changes have been made that anyone other than yourself would see a demo.

In Neil’s process the final step is essentially debugging. Going through the application yet again with an eye for correcting errors, fact checking things, getting a lawyer’s review for liability etc.  At this point you would also ask for the input from as many test subjects as you can, gathering and filtering feedback to fine tune rough edges.  Essentially you want to make sure that if someone is trying your software they don’t have a reason to ask for a refund and they can’t claim that you or your company are incompetent.  The final product has to be great.

Only after enough friends, family and colleagues have used the software that you feel confident in it do you call it done.

It’s interesting to wonder if this would produce a better product than the typical agile developed software.

There are a couple of significant differences in software vs book writing however that need to be addressed.  Software is rarely a single developer’s sole project.  There is usually a team to divvy the work between. This team adds some communication load to the project as people need to be in sync.  This team approach doesn’t work well if all the domain knowledge is stuck in scribbled notes and in the head of  one guy that did the research.  Would Neil’s approach scale to writing a 10,000 page book with 4 other writers?  The counter point would be that if you’re looking at writing a 10,000 page book maybe it would be better to write 20 500 page books and only have a single author per book.

Software is also not written linearly.  When you start to write a book chapter you may be able to start writing and continue without stopping the flow of words.  You probably wouldn’t be halfway through chapter 18 and realize that it would be good to foreshadow what’s happening earlier, then stop and go back through to find a good spot to add that foreshadow element to an earlier chapter. A disruption like that would completely disrupt the flow of your writing.  It’s difficult to write software without jumping around like that.

Programming languages are much more rigorous than English.  it’s not always possible to skip pieces where you need to know an answer to get a working program. There can be hard dependencies that prevent you from moving on until they get solved.  Again this is an opportunity for interruption.

It would be interesting to try this method on a software project to see how it translates.

If you are interested in getting more details from Neil Strauss and Tim Ferriss about the creative process check out this video:

Finding time to code

Finding time to write code after work, when you have an eight month old and a full time job is nearly impossible.  I’m not sure how others manage to do this.

It’s time to do an audit of my time management.  To figure out just where all my free time is going so that I can focus on finding ways to remove my biggest time sucks out of the day.

I suspect that TV time and running errands are the biggest areas that can be optimized to give me time in the day to get more software written.

To be sure, I’m going to do a 1 week audit of my time by filling out this print form.  I’ll share the results next week

Polyglot vs Specialization

I consider myself a fairly well rounded developer. So when it comes time to choose a technology to accomplish a task I will happily choose the one that is the best fit whether it requires Ruby, Python, Java, Objective-C, PHP, CSS, or Bash or anything else.

Recently I was given a project to take on.  At first it looked like it would be adding some PHP code to an inherited code base.  Upon starting it became apparent that the code was a disaster and too far gone to be recoverable… a full re-write would probably be best however it was way out of the budget for now.  Rather than continue patching in the new features we needed, we decided to create a new side project that tied into the existing database to accomplish what we needed.  It gave me a chance to evaluate how I wanted to build this application.

Generally we do Ruby on Rails work with my team.  However given that the existing database schema was not even close to normalized or conventional Rails would have been a difficult way to go.  There would need to be a lot of boilerplate code to map things to new field names.  It just wasn’t a good fit.

Instead I opted to go with a simple, lightweight Node.js App.  It would leverage the SQL queries copied out of the original PHP code with minimal overhead.  The app is heavy on database IO and has zero application logic so Node is a good fit.  We already have Javascript skills on the team and experience with testing frameworks for Javascript code, so support wouldn’t be difficult.

Turns out, it didn’t go over well with some people on the team.

“We use Rails as a  technology stack”

Passion can run high in technology circles over tools. Apple vs. Windows. VIM vs Emacs there are religious fights about which is better.

I like to be good at a breadth of technologies, that means staying sharp on a fistful of languages and tools, while always looking to learn new things.  Others like to focus on being world-class with one technology stack.

Which is the better approach?

Thoughts on Swift

So for an iOS developer like myself Swift is pretty exciting.

When a new language comes along, especially one that is sure to get traction, there is a lot of opportunity to create some exciting new things.  We all know that Swift will make inroads into the mac and iOS app scene, but as a modern language it also has a chance to become something more than that.

Because of the native integration with Objective-C and C libraries Swift offers some interesting opportunities for high performance compiled apps on the server as well.  This is a space that until now has been completely empty on the Objective-C side of things.

The space is wide open to create a Rails inspired web framework for Swift (or Express/Django/Sinatra/etc). All of the key tooling that you have with other languages now can be ported over to Swift.  Things like commandline tool frameworks, APIs for various services, BDD and unit test frameworks.  The space is wide open and everyone right now is on equal footing to deliver the next big thing.

It’s the chance to make a name for yourself in the open-source community by publishing something cool written in swift.

What happens when computers are smarter than you

A few years ago I was working at a finance company doing quantitative stock algorithms and I remember hearing an interesting story.

Back in the early 2000′s there was some buzz around neural networks and their ability to be used to pick stocks.  The company at the time had invested some R&D into creating their own neural network algorithms to help with their trading.  The algorithm performed well and they apparently moved it into production.  However, it was quickly pulled back out.  Even though the trades were profitable, when investors asked why they had made specific trades the portfolio managers couldn’t give them a reason.  An “I don’t know” answer from your highly paid portfolio manager doesn’t instil a lot of confidence.

The neural network algorithm was in someways smarter than the portfolio manager, it could identify correlations in the stock market that could not be explained in terms the investors could grasp.

I believe there is nothing inherent to the bundle of neurons in your head that would make it impossible to replicate in silicon and software.  Furthermore, if it’s possible to replicate the average person’s brain then it’s possible to replicate a brain with an IQ of 200, and if that’s possible then perhaps it is also possible to simulate a brain with an IQ of 500 or 10,000! The ramifications of which are incomprehensible.

Over the last handful of years big strides have been made in the world of AI.  Facebook has face detection algorithms that are as good as humans, Google has self driving cars with a perfect driving record, publishing companies have algorithms to write news articles.

We are fast approaching a time when computers will be smarter than us all.  They will gradually pick off more and more tasks to be better than us until they are smarter in a general sense at virtually everything.

When I look at my profession of being a software developer, I can foresee a way for computers to make dramatic inroads to making even me obsolete. You take all the publicly accessible code online and feed it into a learning system. correlate issues and bug reports to the code fixes and it becomes possible to identify logical errors and bad practices, or autocomplete entire sections of code. Even without cutting out software developers completely, it seems possible to increase their productivity by an order of magnitude.

When a computer is smarter than me at programming, it will program itself.  I will be out of a job, and likely, so will everyone else.

When a computer is smarter than all of us, the entirety of human civilization will change.  We are currently unaware how a system a complex as everything on Earth will react, and that’s kind of scary.  Perhaps someone should attempt to forecast this future.  An economic forecast may have more weight to pull in political debate.

Indie Game Dev Bubble Has Burst

Over the last few years I have published several iOS games. The market place has changed dramatically over that time.

My first game was a simple scrolling shooter. When I released it the initial downloads hit 50,000 and I was ecstatic. With each subsequent game that I released the trend was clear, each one landed with less of a splash, and the number of downloads for each game was lower despite improvements and better quality games.

These days the competition on mobile games is so high that there is virtually zero chance that an indie developer can make it big. Creating a game that will get noticed on the store requires a level of design polish that is very nearly impossible to pull off without a significant budget.  The competition is experienced, well financed and has a team of people creating deep, well thought out, polished games.

If you’re a budding game designer doing it for the love of the code. Go for it! It’s still a lot of fun, and looks great on a resume.

If you want to actually create a business around game development the space to watch now is with selling game source code. Making money off the 1000′s of people trying to create their own games removes the risk of trying to create a hit game yourself and relies instead on people with money who want to try their hand at the market.

Capital vs Labor

A lot is being said these days about inequality. It is an issue that probably won’t be going away anytime soon as the trends continue to push the top 1% of earners even further away from the 99% as the middle class is getting hollowed out.

In the ground breaking book Capital in the Twenty-First Century Thomas Piketty goes into great detail about the real data about inequality over the past 100+ across 10+ countries.  It’s the most thorough data ever compiled on inequality.  The economic theory put forth after examining the evidence is that when the return on capital investments is greater than the growth rate of the overall economy inequality increases.  This seems to make sense intuitively as the families with capital to invest are the ones that see the most gains (on average)

What does this result have to teach us about running a business right now?  Well, we live in a time where capital is returning better than labor.  In concrete terms that means that in the aggregate (ignoring local anomalies) the cost of employees is going to grow slower than the value you get from their work.  If there’s something you can take home it’s that it is a great time to be investing and growing your business.  Hire employees, create products, launch services!  Take your profits and re-invest it – acquire assets, purchase stocks/bonds, and don’t let it sit idle.

On the other hand you will be on the loosing side of the equation if you are the employee eeking out minor raises every year.  If that is your situation then now is the time to get your shit together.  Aggressively get yourself into a position where you have capital to invest (pay off debt, grow your savings). Create assets such as publish a book, write software or invent something (something that doesn’t require ongoing labor). It has never been easier to sell things into a global marketplace.

Interestingly, during the time when the rate of return on capital was less than the economies growth rate, it was a great time to be an employee.  This happened during the golden years between 1945 and 1970 when the classic advice of get any job at the bottom of a corporation and work your way up by being a go-getter actually worked!