Professionalism, Programming, and Punditry and Success as a Metric
Jeff Atwood has one of his best posts in months that was inspired by Alastair Rankine's post "Blogging Horror" explaining why he's unsubscribed from Jeff's blog. I too, have been less compelled to read Jeff's blog lately, but he's an excellent writer and he's consistent, so I read it at least a few times a week. Kudos to Jeff for keeping up the pace and for inspiring conversation.
Alastair says:
"In other words, Atwood seems to be setting himself up as an authority figure on software development and, well, I have some issues with this."
This is something I've struggled with as I've been blogging. I mean, it's just a blog. Look at my first post. Once while presenting in the Midwest a gentleman asked me a question along the lines of "how did you get so good?"
I said, "What gave you that idea? Don't mistake loud with good. Start writing and talking, you can be loud, too."
I like what Dave Winer said that Jeff quoted:
"Blogging is an amateur activity. It's users writing about what they do, not professionals writing about what users do."
I'm definitely not an authority figure on software development. I'll go so far as to put words in the mouth of Martin Fowler (we'll see if he comments), but from my interactions with him, I'd venture to say he wouldn't consider himself an authority either. He's a traveler on the path, as are we. He thinks, shares, asks good questions and starts interesting conversations. What more could one ask from a member of the community?
We're all just learning together. I started blogging so I could Google myself later, that's all. I taught as an adjunct professor so I could know the topics better as there is no better way to learn a thing deeply than to teach it. I worked on a few books so I could really dig deep, but I'm the first guy to say "dude, I have no idea." My brain bit-rots as yours does.
None of us (in software) really knows what we're doing. Buildings have been built for thousands of years and software has been an art/science for um, significantly less (yes, math has been around longer, but you know.) What just know what's worked for us in the past.
There was an interesting conversation in the second ALT.NET podcast (not my show) where the folks in the conversation were disparaging Database Driven Development over Model/Domain Driven Development. It may not be pure, but it must have worked for someone or it wouldn't exist, just like the Scrummerfall Project Management Methodology. ;)
Once years ago when working at a large NW Bank I was in a meeting with a young man who had been hired by a consulting company and had only worked at that one company. He was a "college hire" and had no experience other than "whiteboarding for money." I really don't like to get into measuring contests but I was weak in this instance. I took the bait and said "well, I like to use success as my metric, what have you shipped lately?" It was a nasty room-quieting thing to say and I'm not proud of it. But, I was really frustrated and I didn't know what it was going to take to get it across to this gentleman that we were more interested in shipping software than his brand of architecture astronomy. If you're in college, definitely ship some software or work on some open source applications to get some really good failures under your belt, before you enter the workforce.
One of the things that I enjoyed so much about my recent show with Richard Campbell is that we've both being doing this for so long (15,20 years respectively) that we've go so many stories of failure. Folks are really teasing Twitter for being down all the time. People blame Rails, the blame the team, but think of what they are learning! Even better if they share it with us in detail.
I respect failure a great deal. So does Jeff. Success is a good metric but failure is pretty useful as well - certainly more useful than putting MCSE, MCSD, MC*.* after your name. When I hear that someone has a lot of experience, I'm most interested in their horrible failures and how they dealt with it. My best blog posts have been pulling about success out of crap, fixing bugs, slinging code, fighting with the machine.
Jeff says about himself:
"But I have an ace up my sleeve that most don't: what I lack in talent, I make up in intensity."
Not only am I in no way an expert in software, Microsoft or otherwise, I explicitly assume that you aren't either. I have had conversations with high level VP types at banks who have said things like "I read on this guy's blog blah blah blah, it sounds good. What do you think?" and my questions back at them are "Have you tried it? What do you think?"
The blogosphere is a network of trust, so certainly there are some people that I trust because they make sense and other folks think they make sense also.
Still, ultimately, it's about thinking, talking to each other, and thinking some more. The real content in any blog, this one included, is in the comments, and that's why I like you all so darn much, Dear Readers.
If you've got experience, share it. If you don't, then do some work and fail fast so you can gain experience. Read, write, talk and test. Have fun, write code.
Related Links
- Scott Hanselman, 11 Successful Large Projects, 3 Open Source Applications, 1 Colossal Failure
- War Stories with Richard Campbell
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
>> have been built for thousands of years and software has been an
>> art/science for um, significantly less
Scott, I know that it's popular to say that building is not a good analogy for building, but I'm someone who thinks that software developmetn and building are extremely analagous.
Have you ever had a building project done on your house? If you have, you'd probably know what I mean. Yes, sure you can ask the electrician to put in a few power points as part of the building 'project' but how often do you think that they all end up where they should?
It's the same as software development. There's the image that the project owner has in there head at the start of the project, and then there's the application that is delivered at the end.
I think we can learn more the the failures then from success. The thing I find great about blogs is that it gives me a glimpse into the way people think and also I get to learn loads more from the shared experiences and failures/mistakes.
Shivam Guness
Awesome first post.
Here's what I think of Jeff's expertise: He's in the top-tier of software developers. Why? Because he *cares*, and he *thinks*. I don't know what your experience is here, but that alone puts him in the top 15% of programmers I've ever met. Think about all of the "developer" resumes you go through, all of the job interviews that betray no sense of thought...
People have to ask themselves what they want to get from Jeff's (or anyone's) blog. Jeff broadens my horizons. I write code, but I'd never heard of Edward Tufte... Judging by the commenters, Jeff also broadens their view on what it means to be a progrmamer -- some people are outright pissed that he writes about PC hardware, usability, and standards. "Where is the code?!", they ask. But that's not the point. The point for me is to check back with Jeff once or twice a week and see if he's pointed something out to me that I might want to be aware of...
However, his "The ASP.NET 2.0 Anthology: 101 Essential Tips, Tricks & Hacks" book was excellent with lots of practical information.
In general, none of the authority figures on software development write about security which damages their credibility once you notice that lack.
Atwood aspires to be a writer, but I rather read Dickens or Dostoyevsky.
Dave Winer and I went to Tulane and he used to listen to my radio show, if you ever spend any time with him you'll soon realize that he is his blog.
The best bloggers blog about what they do for a living.
Newspapers and magazines have traditionally lied about their circulation numbers, today's multi-editor super blogs manufacture traffic in the race for a greater CPM.
If it's any encouragement: i don't think you're very 'professionalistic' nor 'authoritativistic'.
On your best days, you're just a workin dude, bloggin' the problems he runs into.
That alone is gold!
Plus, you're a microsoft shill now, but we forgive you for that of course. You do your best to keep it real.
I don't mind that he doesn't provide code. There's a billion bloggers who just post cool snippets of code that they've discovered or have created. And there's a huge need for that. There are far fewer bloggers who talk about the more esoteric aspects of programming, and for that I'm very gratefull for both Jeff and Scott. At my work I'm a generalist a code slinger, DBA, Marketing Director, Operations Officer, Graphic Artist (poor one though), Architect, tester, accountant etc... Wearing that many hats makes you appreciate that the art of programming not only involves the mechanics of coding but an understanding of the bigger picture. Bloggers like Jeff help cast light on some of those 'other' programming issues and help me be more well rounded. Even if I don't always agree with him. If you only listened to people you agreed with, what would be the point?
I really liked you point about failure. I've always been told that the person you put in charge of keeping a system up after an unexpected crash is the one who caused it - because they will never let that happen again. And I also really enjoyed your podcast with Richard Campbell.
I'd like to defend the Alt.NET Podcast discussion on Model/Domain over Database driven development a bit. I definitely agree with you that database driven apps can work, and work well. But they can also fail, and fail in a way that makes it difficult to recover. Its really a fundamental design decision. One of my goals for the podcast discussion is to share experience and I hope the episode you referenced did that. But we're a young podcast and we will do better in the future.
I begin all my talks with a disclaimer: "I am an enthusiast, not an expert." I have gotten tons of positive feedback on that statement, and others have copied it. I don't give talks to set myself up as better than others, I want to stimulate conversations on topics of interest to me. I assume you and Jeff blog for the same reasons.
++Alan
You know, when you apply for a job, you need to rank your skillset from beginner to intermediate to advanced to expert in different areas. I never want to say that I'm advanced in most areas, and never expert. I know some may consider me to be advanced or expert in their eyes, but I always see myself as beginner to intermediate in all areas, because there is so much more to learn.
We truely are all amateurs in this field.
I actually stopped subscribing to your blog (and the blogs of other so called "rockstars") for awhile because I thought too many people were taking everything you guys are saying as gold. I still subscribed to the "unknown guy" blogs, because often times they contain a lot of gold that no one sees because they are blinded (or "star struck") by the "rockstar" blogs. I've since realized that I was missing a lot of good content, so re-subscribed again. But, I still treat all blogs equal, and decide for myself whether what you write is crap or not, no matter how many kicks or diggs you may happen to get.
Mavens are "information specialists", or "people we rely upon to connect us with new information."[6] They accumulate knowledge, especially about the marketplace, and know how to share it with others.
Fantastic!
It's the last word that grabs my attention, "Experiment". I've been developing software for 25+ years. When asked by younger developers, "how did you figure that code out?". I answer "I experiment. When it fails I know what doesn't work. Sooner or later I stumble across what does."
As you have so rightly pointed out, the history of software development in miniscule compared to that of architecture. We are all pioneers in the industry. Every day we move the craft and the science a little farther down the line. Every day is an experiment. And eventually we find what works, right it down, and move on to the next challenge.
Excellent blog post. I look forward to more.
I have came from multi-lango background as i am in love of learning languages but i always adopted to grow my knowledge by learning from my mistakes. I always beleive in that compilers are my true teacher (esepecialy the new breed of compilers) as i learn from the errors and warnings. I learned from failures of fancy architecures and sloppy rapid developments too. So i really admit you are dead right.
I have been a regular reader of Atwood blog and i really like the way he present his thoughts and ideas. He really given me good breakfast to learn and seek the errors inside me and others. I dont mind if some1 can code or not as i beleive that you can even learn from a child too. So i really do care that is it worth spending time or no and he really doing well. You can have difference of opnions with anyone.
P.S. I start feeling ashame about my MS*** & IBM** certs too :( now.
"The difference between a junior programmer and a senior programmer is that the junior programmer thinks he knows everything while the senior programmer knows he knows nothing."
I think it was Socrates who originally said "all I know is that I know nothing"
You make an interesting point about the value of failure as part of a developer's learning process. In today's IT industry, it's difficult to stay within any kind of comfort zone. Things that you're used to doing don't translate to the next big technology. I like to say that dead ends are not dead -- mistakes teach enduring lessons.
But your musings also bring to mind one of the things in the industry I am most ambivalent about -- project failure. We've all heard hair-raising statistics about how many projects "fail". People throw around staggering numbers. It's hard to take the numbers too seriously, because they're often originated by people who have a vested interest in scaring IT decision makers. (Like consultants, for instance). But you'd have a hard time finding someone who would trumpet IT as a model of delivery excellence.
For a good portion of my career, I worked as a one-man shop, or as part of a small company. I delivered some large projects, but there was also a great deal of work with narrow scope. In that environment, failure was out of the question. A project that went bad could easily mean that I could not pay the mortgage, or that the company I was working for would go bankrupt. That wasn't a point of preoccupation, but it was simply a fact. Ideally, I would deliver projects with skill. But failing that, I would substitute sweat and blood. Failing that, it was just force of will to get to the end and make it work somehow. Oftentimes, the client was in a similar situation. Small businesses don't have the luxury of experimentation. They need something that will work, or they face their own bloodbath. Success criteria is pretty straightforward when there is a small group of people who have control over the decisions, whether the project is large or small. And that's what I cut my teeth on.
After many years in a small environment, I moved into enterprise development, for various reasons. Here, success is much more elusive thing. For every project, there are many more stakeholders -- and they have differing agendas. It's not uncommon for someone or some group of people to actively work against the success of a project. But even when everyone wants success, there are many different priorities, and only so many resources to make things work. Best case -- compromises are made to account for differing interests. It's also the situation that these projects aren't do-or-die for anyone, even if the dollar figures are astronomical. The list of reasons that a project can fall out of favor in a large corporation range from wholesale reorganization to a sweet offer from another vendor. And on the other side of the table, the software development company can have its own logical reasons for pulling back or disengaging with a client.
Adjusting to the business environment in the enterprise was more difficult for me than any technical challenges. On the first big, troubled project I worked on, I took it very personally. It didn't even fail, mind you, but I did not have the kind of nuanced view of the development process that you need to stay sane. I thought the world would end if we did not get to the finish line. I was the only one who felt that way.
So again, I agree with you. It's hard for me to imagine someone working in large-scale development for any length of time without facing catastrophe of some type. It's been remarked upon by countless others, but the more complexity and the more stakeholders you introduce into a system -- even when you have very smart people everywhere -- there are a lot of ways to fail. When it's not technical, the lessons aren't always as clear. But you learn. You can always learn.
That's the golden sentence here; nobody should worry about whether some guy thinks he is an authority figure or not.
Everybody has the right to write his thoughts, and it's up to the readers to agree with it or not, to link to it or not, to subscribe to the feed or not, to blog/tweet about it or not.
I would go a bit deeper, saying that: "The blogosphere (just like any other place in the world) is a network where you should carefully decide who you trust" :)
Blog entries are nothing more than a small focused piece of writing with some comments/discussions, where you can get some ideas (to think about), contacts (people to meet and drink beer), pieces of code (to be checked on language references before usage). They are never, never, never absolute stones of truth.
This is true with all blogs, not only technical blogs. You find a cooking blog, where an "authority" says you should prepare a delicious pizza with garlic, tuna, anchovies, gorgonzola and pineapples... would you serve it as your dinner for 20 friends, without testing it before? I guess you won't, so why would you do that mistake for some piece of code? ;-)
Of course there are different level of automatic trust. When I read Eric Lippert's blog on the C# language/compiler that he is actually developing, I am "tempted" to believe in what he says. Some people, on some topics, do deserve some higher trust, but you should never blindly believe what you read in a blog (or on Wikipedia, or in a book, or on TV, or in the street). First, you listen, second, you think, third, you decide.
Isn't it really common sense? :-)
Comments are closed.
Anyway, Jeff is a legend. He gave me and Cartman many hours of fun building my Ultimate PC.
.