Slashdot Mirror

On working at Automattic on WordPress: http://scottberkun.com/yearwit...

http://scottberkun.com/essays/...

Tell that to:

Automattic
Mozilla
GitHub
Basecamp (formerly 37signals) (who even wrote a book about how great remote working can be)

along with a myriad of other companies who work either entirely remotely, or have very liberal policies around remote working.

Most, if not all of whom, can be considered to be quite successful within their field.

No, it doesn't, at least according to this rule: "Any software in this century that reinvents the scroll bar deserves to fail" - http://www.scottberkun.com/blog/2010/lessons-from-wave-and-kin/

I'm done buying LeGuin books

This is just another case of a very intelligent person defending a bad idea. And this idea is extremely subtle to most people who grew up in this copyright society, so I'm inclined to forgive the person, even while giving no quarter on the bad idea.

When you see extremely intelligent family members or anyone you love, vehemently defending things you know to be faulty logic, and you realize you can still love the person despite their stubbornness in their stupidity, then whether you buy the books or not doesn't matter. Because, unless she begins preaching in her books, the books are separate entities, and the stubborn faulty logic in a topic where she is emotionally involved, is unrelated.

After a long spell away from project management, I bought a few books to catch up on what I'd missed. I did read the Art of Project Management, but I wasn't that mesmerized by it (though I did start following Scott Berkun's blog). It felt too sterile and academic as a starting point. Maybe it's better if you're already in the thick of it, and maybe the new edition is cleaner.

What did mesmerize me was Agile Estimating and Planning, by Mike Cohn, who also has a good blog. It's quick reading, in an appropriately lightweight style, and it introduces all the concepts of agile planning (independent of Scrum, XP, etc) in a way that... that...

Well, remember that one professor you had, who taught you biology by deriving it from chemistry from physics from mathematics? Cohn explains agile planning from first principles, in a way that made me wonder how we spent two decades not realizing how obvious it was. My forehead hurt from all the slapping. Of course! Why are we forcing humans to estimate time and to calibrate their estimates? All we know is "hard" and "easy"; estimate in points, track your velocity, and let a smart computer figure out what that means in weeks. Of course! We don't need to plan hour-by-hour for dates 18 months away; we don't even know what we'll consider important than.

If you're considering agile methodologies, you must buy this book. If you're considering traditional top-down/waterfall planning, do yourself a favor - just slap your forehead every day. It'll build up calluses for when you buy the book later.

Here's my 3 steps for getting started before buying a book or doing anything else:

1) I'd recommend talking to your team, individually, about what things on the project are most frustrating or could be improved.

2) In each conversation ask for their advice on what you can do, and also what they are willing to do or try

3) Based on your conversations, propose one simple change that has the best odds of both being accepted, and improving things. If the team has lots of conflicts, pick something very small. If there is too much dissension, pick something you can do with just one or two others.

4) Then make the change.

5) If things go poorly go back to #1.

6) If things go well, propose the next thing from #3.

But without talking to your team, and without establishing credibility and leadership, no book, degree, or IQ, will be of any use to you as a project manager. Start with your team first and earn their trust.

P.S. The book was originally called The art of project management. Making things happen is the 2nd edition, and heavily revised, version of the book.

- Scott Berkun, Author of Making Things Happen

I recommend Making Things Happen: Mastering Project Management (Theory in Practice) by Scott Berkun. Berkun has quite a bit of experience working on and managing teams. You can check out his blog for more info. and to get a taste of what his writing is like.
 
There are a ton of books out there - his blog has a sample chapter to read so you can see if this will work for you. I thought it was easy to read and covered quite a bit without getting bogged down. The table of contents breaks things down to a pretty low level - so that is another good way to see if it hits on what you need or if it might cover a lot of stuff you don't care about. I know I wish some of the people I've worked for had read it and took it to heart - especially the stuff about how not to annoy people.

If you can write a complex system such that a teammate can open any random code file and think "what's so hard about that?"

*exactly*. Its like any other area, the truly talented are the ones who "make it look easy". I'm sure you've seen a sportsman or athlete on the TV, and thought to yourself "I could do that". The problem is that you couldn't, its only because they made it look so effortless that you think you could.

'Devs' like Josh are incompetent in comparison. Often I've found the people who write the most impenetrable code and the ones who think they're the greatest (a worrying sign in itself) and many others agree because they can't understand the code said "genius" came up with. There's a reason no-one can understand it - because its poop. Unmaintainable, probably slow, and possibly only written that way because it gives them some feeling of superiority.

In my old teams they were told to get with the team, or get lost. They're not working for their amusement, they're working for the benefit of the company that pays them.

Scott Berkun wrote a good article about teams and stars. Worth a read.

You are obviously smart, but for whatever reason you're defending an incorrect hypothesis. You might want to look at: Why Smart People Defend Bad Ideas

Unless you're saying you don't get side-stream from people smoking in open air... Then yes you're right, unless you're close to the cigarette.

But if you are in any type of room, it is very easy for someone in this field to determine with reasonable accuracy, how much circulating air the room gets per hour, how the smoke disperses over the entire room (gas does this fairly easily), and thus determine how much smoke one person is breathing in the opposite corner of the room of a smoker.

Don't get me wrong, I agree that smoking in closed spaces (restaurants etc) should be banned (unless you have separated smoking areas).

Air conditioners, for example, cause a high turnover rate of air. You're constantly getting new air. Still, gas spreads quickly, and even with air conditioners, air filtration, etc, a sizable amount of smoke is dispersed throughout a large room if a few people are smoking. The people on the other side of the room are breathing a harmful amount.

Smoking areas do little to nothing in reality. We're dealing with gas here. People believe the notion that a small wall or divider is going to stop gas because they see a visible divider. Tell that to an army chemical weapons department! =P

You suggest optimizing for one quality of user interfaces- "discoverability". But that's certainly not the only user interface design objective. Asking about the user experience after the interface has been learned is quite appropriate, because that's the circumstance that the user will spend the vast majority of their time in, assuming they've stuck around past the learning phase.

The question of whether someone will stick around long enough to learn the software is less one of usability than it is one of marketability. I make no statement about the relative importance of usability and marketability.

I know, you asked not for books, but I suggest anyway this one: http://www.scottberkun.com/the-book-the-art-of-pro ject-management/

It is by Scott Berkun, a former Microsoft team leader. It is well written, and organized in short chapters easy to absorb. It helped me a lot in a similar situation.

This is very easy. The most trivial answer is that
corporate culture sucks a fat one. Project managers are near useless
as they don't contribute to anything whatsoever other than get paid
a ton of cash. Management in general never really know what the
hell they are doing and they get paid a ton of cash for doing abso-f&&&in'-lutely
nothing..

Besides the idiot management that exist, companies love to screw with
their employees. Usually promising one thing and not doing it at all.
Along with that they pay the least amount of money for you, usually below
market value then try to make a ton of money off of you.

In this world, especially with the way things are going now, for every dollar a
company pays you, they expect a million back. Not only do they want to screw
you up the a&& but they would like to screw you up the a&& and force you to
smile because you are getting screwed up the a&&.

All of those stupid software development processes are practically useless.
They neither solve any problems which will further make the software release
faster and they only hinder you from development. The only software processes
that exist are:
1. Asshole Driven development (ADD)
2. Cognitive Dissonance development (CDD)
3. Cover Your Ass Engineering (CYAE)
4. Development By Denial (DBD)
5. Get Me Promoted Methodology (GMPM)
See: http://www.scottberkun.com/blog/2007/asshole-drive n-development/

Don't even get me started about having to maintain old codebases for pay. It sucks
a fat one also having to do this.

Far from truth, there are lots of possible basic improvements for web browsers, especially about bookmarks and the task of recovering previously seen information. del.icio.us success was mainly due to the big need that it solved to this respect, but it isn't enough - much more could be done.

Those findings about bookmarks (in the linked article) have been scientifically validated, but browser developers apparently aren't geekish enough to follow that advice and implement those features.

Excellent post. A good article as well.

Why smart people defend bad ideas:
http://www.scottberkun.com/essays/essay40.htm

He's not working on IE7 for the same reason he didn't work on IE6: because he's no longer working for Microsoft. He left the company to persue writing full time.

His book, The Art of Project Management (published by O'Reilly, no less), is a good read. I read it a couple months ago and pulled it out again just last night to review.

There are specs I wrote for UI features in 1998 that are unchanged today, 7 years later, in a world where browser usage has changed dramatically.

"You're still here? It's over. We won. Go home. Go."