Jacob rails against those who say the differences between modern computer languages amount to nothing more than “syntactic sugar.” Ultimately he argues that: Syntactic sugar matters.

Sure it makes no “technical” difference but it does make a huge difference — because it changes the way we think about writing software.

I’ll loop back to that in a second, but first a quick detour through another recent blog post:

Eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

Of all the cruel tricks in software engineering, this has to be the cruelest…. Even when you’re writing code explicitly intended for the machine, you’re still writing. For other people. Fallible, flawed, distracted human beings just like you. And that’s the truly difficult part.

–Jeff Attwod

The thread that ties both of these together is that they highlight the way that people and by people I mean software developers, tend to forget is that code is always two things:

• A series of instructions or declarations processed by a computer.
• A series of instructions or declarations processed by one or more human beings.

Code is a machine construct, but it’s also a social construct. Software engineering is a strange name for our discipline, since the hard work of programming isn’t just getting code that machines can run, but in creating abstractions that allow human beings to learn, understand, and evolve the code over time. We didn’t invent Structured Programming, or Object Oriented Programming because they help the computer understand what we mean — we created them because they provide us with tools to help us as human beings to be able to understand the code we write.

Non-software Engineers aren’t concerned primarily with the practice of communicating complex thoughts and ideas to others. This is a vast oversimplification, but I think it’s fair to say that they are interested in constructing mathematical models of how things things behave, so that they can build stuff that works.

But that’s not what we are, we are creative writers, we invent new ways of thinking about the world, and we try to communicate them to each other every day.

Software Engineers do create incredibly complex systems, and operate under constraints that other writers do not — what we write has two audiences, one human, and one non-human. Writing for the non-human audience alone will result in code that’s incomprehensible to other programmers, but the opposite is also true. Computer programming is hard — and it’s hard for a very specific reason — because it requires thinking like other people, and not thinking like people at all.

Fortunately, the problem is simplified a bit by the fact that other programmers have learned at least somewhat to think like silicon and metal, so you can lean a little bit in that direction and still be understood. But still you have a very exacting, very alien audience, and a very exacting, very human one — and programming languages must be designed to balance the needs of both.

So, perhaps we ought to stop calling ourselves software developers, software architects, or software engineers, and start calling ourselves software writers.

Children of kings and great magnates were the first to grow up out of touch with the world. Suburbia means half the population can live like kings….

Paul Graham

You can’t shelter people from everything bad or scary, and expect them to live in the real world.

Project managers, System Administrators, and parents should take note of this.

People can only step up and take responsibility when they actually know what’s going on. Seems to me that there are lessons for how we talk to people about project risks, how we handle e-mail spam problems, and how we think about IT services. It’ll be a while before I figure out what exactly all of those lessons are….

Are bowling balls more tasty than love?

Thus pointing out the absurdity of my original question. But now I want to know! Are bowling balls more tasty than love?

But at least with good tools, I can participate this odd hobby in the comfort of my own home.

SSH makes Remote administration of linux/Unix servers remarkably easy. Unfortunately Windows 2k/2k3 requires a GUI for Remote administration, but Microsoft generosity has alloted two Terminal Server Clients for remote administration purposes on every Windows 2000 and Windows 2003 Server they sell. Unfortunately, sometimes you get disconnected unintentionally. If this happens twice, you could get the dreaded “The terminal server has exceeded the maximum number of allowed connections” error.

Now, you can’t even connect to disconnect the old sessions. You’re screwed, and you need to drive an hour to the server and get to the machine and kill the inactive sessions.

Not really, you can just:

start | run - mstsc -v:10.10.10.10 /f -console

This attaches you to the special “console” session, which kicks whoever is logged in locally off and allows you to remote control the machine again. You can then kill the inactive sessions and move on with your life. Always kill the inactive sessions first, because if you get disconnected again you will have to drive in.

Since I normally run Linux at home, I don’t use the above command, I use:

rdesktop -0

I also have a shiny new MacBook which isn’t always booted into Ubuntu Linux, sometimes it actually runs Mac OS X. Have no fear I can use the Remote Desktop Client to connect to the console session:

No fancy command line option here, but you can hold down the command (open apple) key and click the Connect button.

If you control the server, and you don’t have any long running user processes you want to be able to reconnect to on the server I highly recommend also setting up your servers to automatically disconnect inactive sessions.

That way even if you get disconnected, you just have to wait a few min. until the first connection to drop times out.

Hopefully, that’s all sorted out, and you can register at the PyCon site. If you’ve been on the fence about that, today would be a great day to sign up, since PyCon registration will cost $65 more if you wait until Tuesday.

I’m excited about all the interest shown so far, and I hope some more people sign up, because it looks like there’s going to be some extra cool stuff released in the next month, and I’ve gotten to see some of it and it looks fantastic. So, I would expect that there will be some interesting new stuff to cover in Tutorials, even for all you old hands out there ;)

But I know that the image of the pointy haired boss is pretty thoroughly ingrained in our culture, and popular mythology exists to explain a shared experience.

Clearly there are a lot of bad managers with MBA’s from prestigious institutions out there.

Henry Mintzberg does more to explain how this happened — and what we might be able to do about it — than anybody else I’ve read recently.

The central argument of Managers not MBAs is that Management as taught by MBA programs is a failure, because they:

• choose the wrong people,
• educate them in the wrong way
• and produce the wrong results.

In other words, the selection process and educational format of most MBA programs actively undermines the practice of good management. MBA’s are a self-selected group of people who “want to get ahead in business,” and the entire program teaches them to compete rather than cooperate.

The result is that graduates of MBA programs have a pretty dismal record at actually starting, expanding, or maintaining stable, productive, businesses.

Mintzberg doesn’t blame MBA holders — they were taught strategy, and accounting, and analysis, but never management.

In particular, MBA programs never taught them the meaning of good management, or the skills they would need to actually grow and manage teams of real people. They aren’t even pointed in the right direction, the structure of MBA programs reward the kind of people who like to compete. And years of “case study” exercises have made them into the kind of people who make snap decisions based on limited data.

MBA graduates generally aren’t the kind of people dedicated to helping other people achieve greatness.

Instead, they want to achieve greatness on their own — which can be a worthy goal. It’s just a terrible goal for a manager. Good managers are relentlessly focused on helping the people they work for perform at their best.

I don’t believe an MBA degree is just a liability.

The MBA’s I know have learned useful terminology, analytical skills, and the training they recieved in in economics, accounting, and business law can be a huge help in the right moment.

An MBA can prove to be an net asset to a manager, but only if you unlearn some skills they teach you (snap judgments, and me-first competitiveness) and make it a point to learn the “soft” skills that are infinitely more important.

The second half of Mintzberg’s book is his proposal for creating better educational institutions, which can identify the right candidates, train them with the right skills in the right way, and ultimately produce much better results than current MBA programs. The broad outline of that plan seems right. But most managers need something they can use to get better at their jobs right now, without spending a lot of money.

• Never stop learning from the people on your team – they are on the front lines learning every day, if you’re not working to learn from them, your loosing potentially critical information.
• Always believe that there is more to their job than making money. Greatness comes from productive passion, and greed doesn’t inspire passion or loyalty.
• Elevate the people who actually produce value — These people actually do the work, and they know infinitely more about the nature of that work than MBA trained managers, so they should be respected, valued, and included (or put in charge) of improvement processes.

Good managers care about people, not head-count, and they strive to make their job a meaningful contribution to a shared vision.

Hopefully I’ll have time to write more about good management tomorrow.

There’s no such thing as a totally secure computer environment, and a recent study shows how easy it is to subvert one modern voting machine. But don’t let the fact that they only broke into one brand of machine fool you, nobody is going to make a totally secure voting system. When the stakes are high enough, whatever security you have will be hacked, and we’ll have voter fraud. And even if you could be 100% sure that the machine wasn’t tampered with, it’s impossible to be completely sure no bugs have screwed up the totals?

As Software professionals, we need to speak with one voice on this issue. Bruce Schneider explains what we all pretty much already know:

Computer security experts are unanimous on what to do…

1. DRE machines must have a voter-verifiable paper audit trails…
2. Software used on DRE machines must be open to public scrutiny…

I know I’m pretty much preaching to the choir on this blog, but I’m also commiting to explaining the need for voter-verifiable paper trails to a dozen non-technical people over the next two weeks. If you can, I’d ask you to do the same thing. And if you have a blog, please ask your readers to do the same thing.

This isn’t about party loyalty, it’s about preserving democracy.

How many products have you bought with million dollar marketing budgets, and not enough money to create a manual written in something resembling english, with reasonable diagrams?

Users are your best advocates, word-of-mouth only works if your users have a great experience.  As Kathy would say, if you help your users “kick ass” they will tell their friends.

Which brings me to my real point, manuals are important, but most of the time people expect them to suck and they don’t even read them.   So, even if you write great manuals, you need to think about how to market your manual to your users.

This isn’t some hypothetical post.  The software we sell at Humantech has fantastic manuals, which we spend a lot of time and money polishing up, and they work!

I’ve yet to have a support call from a user who read the manual, and nearly every support call can be solved by reference to the manual.    But people still don’t read the manual unless we prompt them.

I can usually “sell” the idea of reading the manual to any given user in the space of a support call, and once they read it they always thank me.  But we need to find ways to make our manual more “attractive” so that new users actually read it without need to be individually “sold” on the idea.
Let me know if you have any ideas/experience marketing your manuals to your users.

It’s a pretty high priority for me right now because I’m convinced that it could free up quite a bit of time and help our users have an even better experience with our software.

Thank heavens I found Getting Things Done last year — without a trusted system outside of my head for all my to-do items my life would be falling apart and my stress level would be insane.

In about a week I’ll be able to get back to blogging, and I have a half dozen article stubs just waiting for a little bit of attention, so I hope it will be worth the wait!

“I don’t grow apples. I grow apple trees.” One is a result of the other. Overly focusing on the apple can cost you the tree.” –Jared Richardson

If you throw together a team to build a product, you might get lucky and create a great product. If you are really lucky you’ll get a great team that works well together, is motivated to build amazing software, and is starting to learn and grow as a group — not just as individuals.

Unfortunately, the next step most companies take is to pull that team apart, promote some of them, and try to start all over again new products with new teams. This is a colossal waste of time and money. Great companies find ways to re-use existing teams who have already learned to work effectively as a team. I’ve found that small companies, who have no choice but to re-use the same teams over and over again, have a competitive advantage over their larger competitors who constantly reshuffle their product development teams.

If you constantly grow your capacity to build great things, your competitors will always be playing catchup. But if you slow down and focus on your current cash cow the milk will eventually dry up.

Sometimes I am worse than I was yesterday, either because I am tired, or I’m distracted, or I just have a headache. And that can be a problem — after all I should be getting better — not worse.

These feelings of guilt are very much related to the problem I discussed in “Always doing your best considered harmful?”

I feel like I ought to always do my best. The problem is that when your best changes day by day, hour by hour, you’ll never be doing your best by some definition of “your best”.

The other day in my annual review we were talking about how I helped someone in my team with managing his tasks and priorities. This individual had definitely turned a corner and the same people who had criticized him a few months earlier were now singing his praises. But I wasn’t as happy about this as I should have been — after all I should have helped him turn this corner months or years earlier — it turned out to be so easy. All I had to do was re-define his job requirements in terms that motivated him. He is a real people person and doing everyday project work was hard for him, but when the work was framed by who he would be helping and how it would make their life better he was happy, even excited to do it. All I had to do was tell him “your job is to keep X, Y and Z happy by doing A, B and C,” and he clicked into gear. Why didn’t I do this a couple of years ago?

Because I didn’t know what needed to happen yet. I’m working to learn that there is no shame in getting better — even though that means that I used to be worse.

Andy Hunt (one of the authors of The Pragmatic Programmer) blogs about how Ford Motor company is explicitly logging the amount of time their employees are spending in the bathroom. This tells their employees that they are not trusted, and it saps the morale, creativity, and eventually the productivity of their workforce.

Clearly this initiative required IT support, and while I don’t suggest that IT Departments make it their practice to regularly second guess business decisions, I do think somebody should have thought longer and harder about how reasonable it was to spend time and money installing key card readers, writing a system to track time in the bathroom, and provide nice reports to management.

Besides this kind of micro-management is pure waste. Does your customer care how much time your employees spend on the toilet? I seriously doubt it. They want products that are cool, reliable, and reasonably priced — all the activity you spend tracking other things is wasted time and energy.

And, if you happen to have an employee who gets more done in a week than any of your other programmers, but for some reason spends more than the average amount of time in the bathroom, is that a problem?

Tracking the wrong thing can get you focused on “solving” non-problems, and that’s another common form of waste.

One of the key elements in the success of Lean Manufacturing is that it empowers individual employees to improve their jobs.

Toyota workers have been able to decrease costs, improve productivity, and reliability — every year for more than three decades. They were able to do this because management trusts employees to shut down the line at any time whenever they see a problem that needs fixing. They where able to do this because there were processes in place that encouraged, and even required their participation in the improvement process.

I’ll take this one step further — if you don’t learn to trust your employees you won’t be in business for long.

If the people you hired are trustworthy, trust them!

If they you have employees who have demonstrated a lack of trustworthiness, let them go!

If you aren’t trusting your people, you are slowly but surely sapping their morale. Even worse, you are cutting yourself from the source of real ground-floor process innovation.

Toyota workers have constantly been able to decrease costs, improve productivity, and reliability — every year for more than three decades. They were able to do this because management trusts employees to shut down the line at any time whenever they see a problem that needs fixing. They where able to do this because there were processes in place that encouraged, and even required their participation in the improvement process.

How many IT shops have the same track record of continual improvement in customer satisfaction and overall employee productivity? Not too many. Perhaps one of the reasons is that we don’t empower our employees to give estimates, or to make budget decisions.

Software development shops could do with Kaizan events where take out a day to:

• automate build processes,
• create test frameworks,
• update our version control systems,
• and clean up any of our processes that has gotten messy.

These events should include the development team, whatever System Administration support is necessary, but managers who attend must be willing to work as team members to get things done. Just for the day, your job is not to lead, but to do, to work along side the front lines people.