24 Apr

Paul Graham – Maker’s Schedule, Manager’s Schedule

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

via Paul Graham – Maker’s Schedule, Manager’s Schedule. I understand this feeling, I just never knew how to describe it.

14 Apr

OnStartups – Forming a new software startup, how do I allocate ownership fairly?

For many companies, each "layer" will be approximately one year long. By the time your company is big enough to sell to Google or go public or whatever, you probably have about 6 layers: the founders and roughly five layers of employees. Each successive layer is larger. There might be two founders, five early employees in layer 2, 25 employees in layer 3, and 200 employees in layer 4. The later layers took less risk.

OK, now here’s how you use that information:

The founders should end up with about 50% of the company, total. Each of the next five layers should end up with about 10% of the company, split equally among everyone in the layer.

via OnStartups – Forming a new software startup, how do I allocate ownership fairly?. Perfect and beautiful answer to an incredibly hard problem.

13 Apr

The Official Website of Eric D. Snider – Snide Remarks: Leaving in a Huff

One thing you may not know about me is that I am a writer. More specifically, I’m a freelance writer. This means I can have several clients at once, work from home in my underwear, and set my own hours. It is basically like being a prostitute, but with less stringent hygiene requirements.

Up until last week, one of the places I wrote for was Cinematical, a fine website devoted to news and commentary related to the film world. But now Cinematical has essentially been run into the ground by its corporate overlords. The writers were let go on Wednesday. The editors had already quit. What happened to this once-thriving movie blog? Gather ’round and pay heed and I will tell the tale!

via The Official Website of Eric D. Snider – Snide Remarks: Leaving in a Huff. This is just an awful tale of corporate stupidity, mis-communication and a company seemingly doing everything possible to make their employees feel awful.

24 Jan

The New Yorker – News Desk: Why Is Eric Schmidt Stepping Down at Google?

Was Eric Schmidt pushed or did he jump? Both. According to close advisors, the Google C.E.O. was upset a year ago when co-founder Larry Page sided with his founding partner, Sergey Brin, to withdraw censored searches from China. Schmidt did not hide his belief that Google should stay in the world’s largest consumer marketplace. It was an indication of the nature of the relationship Schmidt had with the founders that he—as Brian Cashman of the Yankees did this week—acknowledged that the decision was made above his head. He often joked that he provided “adult supervision,” and was never shy about interrupting the founders at meetings to crystallize a point. In the eleven interviews I conducted with him for my book on Google, he freely told anecdotes about the founders, sometimes making gentle fun of them, never seeming to look over his shoulder. Yet he always made clear that they were “geniuses” and he, in effect, was their manager. After a bumpy first couple of years after he joined Google as C.E.O. in 2001, they had developed a remarkable relationship. But also a weird one. How many successful organizations have a troika making decisions? Schmidt, according to associates, lost some energy and focus after losing the China decision. At the same time, Google was becoming defensive. All of their social-network efforts had faltered. Facebook had replaced them as the hot tech company, the place vital engineers wanted to work. Complaints about Google bureaucracy intensified. Governments around the world were lobbing grenades at Google over privacy, copyright, and size issues. The “don’t be evil” brand was getting tarnished, and the founders were restive. Schmidt started to think of departing. Nudged by a board-member friend and an outside advisor that he had to re-energize himself, he decided after Labor Day that he could reboot.

via The New Yorker – News Desk: Why Is Eric Schmidt Stepping Down at Google?. Typically when I’m posting to The New Yorker, I’m talking about how it’s a super long article with tons of detail and sources. This is super short article but man it details the entire story of Schmidt leaving Google as C.E.O. In all honesty this should be used as an example to journalism students everywhere.

22 Jan

Rands In Repose – Managing Nerds

In front of you is The Problem. While I don’t know what The Problem is, I do know that you have a bright team of talented nerds working for you, and I know that you don’t have a clue how to tackle The Problem: you need the nerds and you don’t know where to start. The Problem is unique in that your normal leadership moves aren’t going to work. You can already predict the collective nerd reaction and it’s the opposite of what you need to happen.

Rather than attacking this Problem directly, let’s turn it around and explore the inner workings of your nerd’s mental landscape for inspired next steps.

via Rands In Repose – Managing Nerds. How does one go about managing nerds.

01 Aug

Review/Summary of The Mythical Man Month

The Mythical Man Month is one of those seminal works of software engineering that praise is heaped upon and quoted at most if not all software firms. The book itself is perhaps most famous for popularizing the rule that “adding more programmers to a late project makes it even later”. This however is not the only conclusion to be gathered from this book.

The Summary

The book should perhaps be most praised for being written in a manner that the engineer in me can get behind. Short and fast chapters with not a lot of fuss of double telling a point after it has been made. Including a bullet point review of the book, it is a short 300ish pages long. Perhaps the largest complaint of the book is that the focus of the book is upon system or what is now known as embedded programming. That being said there are a great many points to be gathered from the book.

The first is that there are several different types of programs, simply a program, a programming system, a programming product and finally a programming system product. Only the last is one that is the goal of most programming teams. The first is essentially something that the programmer can use and build in the course of a few days or weeks of effort. The second and third are required intermediaries to the fourth but moving in opposite directions. A programming system is where a program becomes a part of a larger project. This requires the program to mandate all input and output to be semantically valid and correct, to be on a well-defined budget of resources (be they computer time/memory and i-o limitations) and to play well with other program.

The programming product requires a vast suite of test cases so that other programmers may rely upon it and through documentation so that others may extend it’s feature set. Each of these two intermediary steps requires in the authors words “three times the cost of the earlier one”, so that together the programming system product “costs nine times as much”.

Still inside of the first chapter, do we get the next great revelation; programming is a fun and abstract art. This leads to its own set of problems, least of which is the abstract part. Perhaps the greatest of these is the requirement of perfection demanded from computers. The list of problems quickly grows in the next few paragraphs, being at the whim of others decisions and others goals, depending upon others perfection for a programmer rarely works alone in all aspects of a project, the design is more fun that actual implementation, debugging becomes more difficult the further one goes, and finally that rarely does it seem to be ahead of the curve more often than not it feels that the project is already obsolete before completion.

I love the image that the author weaves here of Software Engineering being a tar pit and him trying to “lay some boardwalks across the tar”.

Scheduling software is a notoriously dark art. The author brings forth a simple and basic rule for dividing up the time on a software project.

  • 1/3 Planning
  • 1/6 Coding
  • 1/4 Component and early system test
  • 1/4 Systems test, all components in hand

The next bit is the most famous of the conclusions from the book in which the author discusses how adding more people to a project doesn’t make it any sooner to completion, if anything slows down the project overall. There is the matter of both training these new engineers on the inner workings of the project before they can even be brought into working on the project on anything approaching a full-time basis, the next is that as you add more people there develop more lines of communication and more time to delegate and split tasks into manageable pieces for each person to work on. Essentially far easier for two people to meet and decide on two parts of the project to tackle, far harder for three, four or five people to meet and delegate the project into x number of pieces for each to work. Especially for the task to be divided in such a way that you are both accounting for one’s abilities and trying to time the project so each finishes at roughly the same time.

The author coming from the discussion of how more people on a project leads to an overall slowdown in the project argues with more data than any other section for a “surgical team” to tackle projects, even those ridiculously large ones to be split into manageable portions for surgical teams to take on as opposed to “hog-butchering team”. Essentially for a coordinated effort by one or two programmers with all others acting in support of those one or two programmers.

The vast majority of the rest of the book espouses and stresses these points in some way or another. From espousing that a good design (note design here terms of design of the architecture not design in look and feel) can only come from a single or extremely limited number of persons. That architects of systems of a system have a tendency to over design to achieve complete interoperability and extensibility. Assigning value to both the number of bytes and time needed for a function to complete is a good way to limit over design.

There must be both formal and informal level design documentation. Intercommunication and organization are requirements for even a decent project to take flight not just among team members but across all teams. The author argues for daily meetings for all team members with weekly inter-team meetings. He also argues for some form of a project workbook to collect all changes and thoughts of the team members so that anyone reviewing or testing a section has complete access to all knowledge of that section on the spot. At the same time the author argues for all team members being required to see and read the workbook, at a later date he becomes convinced otherwise and instead stresses that the information be made available but not in essence required reading. Plan for throwing away an initial version of the project. Iterate quickly on a project, create a working version as quickly as possible and keep up it’s working state throughout the course of the project. A project does not all of sudden become late but rather over the course of one piece taking longer or one day of missed meetings.

Documentation while hated is a really important feature for a good project, not just for the customer but for programmers to know the why behind a piece of code. Re-using or purchasing that which has previously been done to save lots of time and effort than in effect re-creating the wheel. Adding functionality to software in a piece-meal fashion, rather than all at once.

It’s all in all a long list of points for such a short book and perhaps most interesting for being such an old book espouses some ideas that I would have thought not in practice until much later.

The Review

Overall wonderful to read, super fast and easy to read. Lots of examples and data points from basic research to analogues and one-off stories to provide force behind each point. The majority of the points I would take little to no time to critique except for that it focuses heavily on systems programming and hence not in an area that I find myself (and probably most modern programmers) working in. Little effort to none is made for focusing on the actual usability of a project beyond that of other programmers, whereas most Software Engineers find themselves writing code that a normal human being will interact and deal with. The book also develops a ten person strong team with just one or two people actually devoted to writing code. This seems more than a bit of overkill. I would suggest something much closer to the 37Signals plan, one manager, two programmers, one designer and one tester. Perhaps my smallest critiques is the focus on “man” hours as opposed to person hours, also the little one off here and there of using a religious idea as proof for a software engineering plan. For instance, in the bullet points on using two core programmers on a team the author makes a footnote of “Note God’s plan for marriage”. Minor annoyances I admit but they detract from an other wise well written and developed ideas.

I would recommend this book to not just Managers of software projects but also to the programmers under their leadership in the hope that they understand better the difficulty in creating an outstanding “programming system project” and quite possibly how to build a better maintainable project.

31 Mar

Bits, Features, and Truth – Rands In Repose

Now, a name belongs inside each of these circles and it’s the name of a specific role on your team. The traditional titles for these roles are engineering manager, product manager, and program manager, but I don’t want you get to get hung up on titles. I want to you to think about the person who is best qualified to make a decision regarding the bits, the features, and the truth.

via Rands In Repose: Bits, Features, and Truth. Rands on redefining the common argument between time, quality and features with what really needs to be considered, the bits, features and the truth.

07 Dec

Let’s Talk About Meetings

Meetings how about you and I talk. Why are there so many of you, why do they so often turn into present and inform sessions when they should be plan and decide. Why is it so easy to schedule one of you, 30 seconds of work and an hour of 5 people’s time is gone like that. Their productivity for the afternoon too is shot.

My new plan for meetings is pretty simple:

  1. Monday: Management, departmental and office/company wide meetings
  2. Tuesday: Client and vendor meetings
  3. Wednesday: Project meetings
  4. Thursday: Different client and vendor meetings than Tuesday
  5. Friday: no meetings of any sort, no matter what

That’s it no meetings outside of this schedule if you need to talk about something, wait a week, plan your future meetings better, discuss more over email or Basecamp or something, stop killing my productivity by having meetings.

Exceptions: informal discussions (hey let’s talk about what x looks like for 5 minutes) sure go ahead and have them whenever and wherever, formal/private meetings (firings/company closing/discipline) again do those as needed, everything else don’t do it. If you find yourself emailing a group of people and finding a time and place to discuss something it’s a meeting – pick the right day and wait till then.

The two biggest creators of useless meetings, presenting information when it could be more accurately and economically done in another fashion (video/email/phone/etc) and having people there who aren’t part of the core discussion.

Meetings in the word of Stephen Colbert “You’re on notice!”

Meetings On Notice

Meetings On Notice