It seems to have become a common phenomenon to explain how much more you could do, how much better results you could produce, how much more talent you could expose... if you were only given the chance.
Stop whining and get to work. I'm not doubting you at all - I've struggled all my work life to carve myself a role that allows me to fully leverage my personal talents and to work the way I want to. I think I've come pretty close now, but it has taken several intermediate positions, some political work and most of all, swift, well-planned and courageous moves - including giving up or turning down a few management positions.
Proper casting - that is, the matching of people's talent and the requirements of different roles - is a key element of an organization's long-term health. Your manager should do everything he/she can to put your abilities into use and maximize your motivation. On the other hand, you are the specialist when it comes to your dream role, and it's just possible that casting isn't your manager's forté either. You are the one who should actively pursue your ideal job.
If you've done everything within your power to lobby your ascension to the dream role where you'd actually be at your best but still can't reach it, you have exactly two choices: Swallow your pride and become a content average worker - or change the scenery. I recommend the latter, as life is a bit short to be wasted. But do remember the realities: It's not like the next company were much more likely to automatically cast you correctly just based on your interview. Be sure to work hard enough so that you really know you've done everything you can.
Much of today's work life is total chaos in a positive way. Most of the things you want are available for grabs, but often you must stretch yourself - not just once, but for years. Selfish gain-seeking won't work for long, but balanced and responsible plans tend to execute more smoothly. Spineless worms will end up doing what they're given - active participants in their social environments tend to end up in the chooser role. Get out there and be the change agent!
As the fall progresses, some changes are beginning to affect my life. Finally, one might say! The most important of them is the fact that I'm slowly getting into the job I'm supposed to do. I've been the Chief Software Architect at our company for half a year now, but much of what I've been doing has still been linked with the past and the strains of everyday projects, thus leaving much of the real company-wide architecture planning into a side role.
That, I hope, is now changing in a more permanent way. The project tide is slowly turning away from me, and my focus - as well as the focus of my closest colleague, Sami - will now gradually shift more fully to the more generic productivity and technology issues within the company. What does this mean? In practice, we have three focus areas:
While all of this has been in our agenda for the last half a year or so, the forthcoming changes should provide us time to actually realize some of the thoughts we've come up this far. We expect it to be both fun and productive.
On another note, my fiancee Riikka is starting her new job tomorrow as a System Designer in TNS Gallup, a Finnish branch of TNS Global. All of this is new enough not to have made its way even onto her home pages ;-)
Flux indeed!
There used to be a time when spamming was limited to mass sales articles. Viagra and things like that have an immense marketing potential, and at least I could convince myself to believe that the spam-based sales originated from less advanced home users who didn't realize the global impact of the economy they were feeding. My beliefs have suffered serious blows. Although majority of the spam is still aimed at mass markets, there's been more targeted stuff too.
Today an ad from a French software company called Novalys managed to squiggle through my double spam filters. It says "Dear .NET user" at the beginning, and is sent to my email address used exclusively for newsgroup postings. The signature even says "Microsoft partner", and the footer assures "You're receiving this email because we thought you might be interested in VG news"... Well thanks, but you're obviously mistaken. While something called Visual Guard certainly sounds interesting, I don't need it.
Well, what can I say? Avoiding dealing with organizations that rely on destructive marketing measures is something I can do. I wouldn't place my spam ethics before a customer's benefit, but in a 50-50 situation I'd definitely tip the scales against somebody who blatantly ignores the Internet rules of conduct (and some legislation, too). I hope many of you will do the same as well. Software developers need not support this sort of dark economy. Truly excellent products have many great - and free - advertisement channels already.
It's been an interesting fall. I've been doing so many different things that I've lost count. On the programming side, I've been tinkering with Whidbey (finally out!), SQL Server 2005 (Reporting services rock), WinFX (looks very nice, but I have barely scratched the surface) and a lot more. For work, there's also been a huge load of administrative - but interesting! - stuff and even some consulting gigs. On the hobby side, there have been plenty of time consumers such as POV-Ray, Civilization 4, disc golf, geocaching and photography. Studied some, bought a new Topfield PVR and a 32" LCD TV. And hey, we're also engaged now :-)
It chills me to see that in spite of all this, there's a monstrously long list of things I've neglected. From the top of my head: Bugzilla, ODP, Usenet, the railway hobby, this web site, more studying, more reading and staying up-to-date with what's really going on (I even read newspapers on a three-day backlog), ... The list goes on.
In situations like this, I'm usually the first one to talk about setting priorities. However, I'm having a surprisingly hard time juggling all these balls this time. Following all these diversions has resulted in no net direction - it would be rather hard to define the way I've moved "forward" (to whatever direction!) after summer. Usually it's been easy to identify some key achievements for every few month period. Now it's certainly not.
The intention of this blog post is to say I'm alive. The list of my bloggable subjects is about 8 pages long (10 pt font), so I've certainly experienced things I consider worth saying. Now I just need to find out if writing really is high enough on my priority list.
In late July Microsoft published IE 7 beta 1. But what? It's not public! Now it's time to scream! Really, reading the IE team blog's post with all its comments is... enlightening. I'm a bit surprised we've got to the point where people start whining when a beta isn't public - it's not like public betas had been the standard operating procedure all along anyway. Of course, open source projects have a different concept of beta releases, but why should it be so for commercial applications?
A public beta is making your users test the software for you. This is something people loathed at a time, saying that software houses should do the testing stuff themselves. Of course, a beta is also a chance to see a preview and get ready for new technology, but still - early betas rarely always provide truly useful insight into the interesting new things. It's mostly about testing and reporting bugs, really.
Contrary to what one might initially think, getting as many bug reports as possible is not beneficial for the quality of the product. Getting as many bugs reported as possible is what you want. Although more testers provide more feedback and thus more useful findings, the signal/noise ratio drops dramatically as the number of eager testers rises. Remember some of the Mozilla suite's releases when bugzilla.mozilla.org was flooded with duplicate/invalid bug reports?
Now, if Microsoft has the testing department that's sufficient for the product's current phase AND they know IE7 is unfinished enough not to be ready for everyday use, why should they release a public beta that's bound to get them kazillion bug reports on issues they already know about?
Looking at the various reports people have written on IE7, I'm inclined to believe this wouldn't have been the phase for a public beta. But as a more general phenomenon: Microsoft's first betas have often been rather shoddy tech previews. Beta 2s, on the other hand, have often represented nigh-production quality. It'll certainly be interesting to see both IE7B2's quality and release model. At least a lot of promises have already been made.
There are several roads to quality software, and not all of them involve slipping out pre-production software to everybody who happens to want it. Different resources and methodologies give room for different approaches. At the end, judgement by final product is the only fair way.
Sorry to have disappeared without proper notice! The fact is that I've been on summer holiday since 2nd July, and not blogging was one of the less conscious decisions I made back then. But in 67 hours I'll be back at the office with all the old routines and new challenges.
The holiday has been an interesting albeit quiet one. A couple of trips (one to Middle Finland, another one to Paphos, Cyprus) and quite a lot of just hanging around. Oh, we also picked up a new hobby: geocaching. Although I've spent quite a lot of time away from computers, I've also written some code on Whidbey. I'm more and more excited and looking forward to getting .NET 2.0 into production use. The coming fall with certainly be rich in this regard. I'll post more on this later on.
Right now, I'm off to the Assembly demo party to spend some of my last holiday hours. :-)
Mikhail Arkhipov explains how to get a window office at Microsoft. Interesting - most organizations wouldn't have the guts to value years of service over organizational position.
Actually, valuing and rewarding people by years spent on the job has more sense to it than it sounds at first. But perhaps only if the organization gets quickly rid of nonproductive people?
The bicycling season is now officially open for me. I aim at going to work by bike for half of the year (April - September). Although the first days are filled with pain and fatigue, the positive effects are coming already. The dose of oxygen before work is a great performance booster, and of no less importance is the relaxing ride home after-work. What a great way to forget your stress!
Now that work was mentioned: I had an interesting 7-hour meeting on application security with a nice professional group of people from various companies. While the basics of web application security are rather simple, they're surprisingly badly known to most developers. The dangers of XSS are not fully realized, and most people simply don't understand the huge risks involved in SQL injections. There is a tremendous need for more readable, compact information. Framework support is necessary but not sufficient by itself.
Web security in a nutshell: Most vulnerabilities are the programmer's fault. A trivial slip causes catastrophes. You cannot buy a product to fix what the coder has broken. The only way to really improve things is by boosting the security skills of the organization. Learning is mandatory. Those working with me are thus forewarned. :-)
As requested by quite a few, the RSS and Atom feeds on this blog now have the full content available. I don't actually even understand why MT only picks a short excerpt by default, but there's nothing a little template editing couldn't accomplish.
When I started working at Blue Meteorite last summer, I foresaw myself as building the background architecture for web sites. It didn't go exactly that way. But, after several diversions and detours (great ones, though!) I'm slowly back in the web business, having spent the first six or so months with requirements analysis and Windows Forms apps.
To cut a long story short, I have been appointed Development Manager in charge of our publishing framework (or content management system, if you will), Meteor. My main task is to work with the product's chief architect to set the future direction for the system, both from a conceptual and a technology perspective. Of course, it's a both a time consumer and an enermous source of challenge and inspiration.
The near future should certainly be a time of learning for me. Although I've been working with the web and communication both in the publishing business and the public sector, the perspective of a software vendor is rather new. Particularly, trying to find the balance between product development and customized service provision is a worthy challenge. I expect to know much more in a few months... and really look forward to it.
Uh... I accidentally blacklisted the string ".." on 16th March and didn't realize it until yesterday night, so any blog comments having two consecutive full stops got flagged as spam and rejected. Sorry (and thanks to Max for notifying me on this)!
I could go into a lengthy rant on how software should try to keep the user from making such mistakes, particularly as this one was added by MT-Blacklist's automatic blacklist addition... but since it would sound like trying to pass the blame, I'll just shut up and suffer. Rule number one: Never confirm without reading what you're confirming.
The Boot Camp has been survived - I'm still alive and now equipped with a fancy diploma, a hefty stack of hands-on lab exercises, a little bit of new knowledge and not much else. It would be unfair to say I was disappointed by the course - but pretty close. Two days of a new platform, and all they did was show us a bunch of demos and make us work on some (admittedly really good) exercise tasks.
Trying to keep the rant short: It's ridiculous to just pour as much information as you can during a two-day course. It'll never sink into anyone's head in that time. When people don't learn, they'll blame themselves ("I guess I was told that, I just didn't understand"), so it's basically a good deal for the business. But how about spending some more time actually teaching the issues and making sure people really remember something after the course is over? What's the worth in stating "ASP.net 2 has a provider architecture" if people have no idea on its impact on development practices?
Knowledge is relatively easy to distribute, understanding far less so. If I go and get tutored by professionals, I'd really expect more than just recitals of press releases and published tutorials. But here at work again, I'm still facing the same basic problem: Knowledge does very little as long as you don't truly understand how a feature should be used. Dabbling in new technology is cool, but making it work in a production application requires so much more. Hey... It's called experience. Too bad only few educators are ready to share theirs.
To avoid being totally negative, many Whidbey-related things handled (well, "mentioned" would be more accurate) during the course make great subjects for some blog posts. Also, I finally look forward to clearing my task backlog during the weekend. I'll be back.
The winter holiday season is slowly turning to its end, and perhaps not a moment too soon. Not that I didn't enjoy all the traveling and stuff - I certainly did and the time off was great - but the backlog is getting ridiculous. My Bugzilla review queue is at its all time high, there are about 150 reasonably important emails to be handled and quite a few other things to do before I'm back in normal operation.
A few quick notes from my holidays (and the books I read):
Pelican Brief was decent. I still need to read a few more books from the Clancy/Grisham/etc. clan to be actually able rank them, but I look forward to it. Some light literature was a nice break from the routine. Well, how about the more routine IT stuff then?
Writing Secure Code is a must read for everybody in software development. Despite being Windows-oriented, many of the concepts described in the book contribute to a healthy generic understanding of many security issues. Fully reading and understanding the book would take weeks, but even a few hours of browsing it will give you many good ideas on improving the security and privacy aspects of your application. Definitely recommended.
UML Distilled, 3rd Ed. was another interesting read. I wouldn't embrace it as warmly as I did for the security book, but a good read nonetheless. The innate heaviness of UML gets thrown away on the introductory pages, and the book itself is a critical overview of the most useful elements of UML. Well, that's certainly something different from the usual reference-tomes. If you already know how to model things and want to do it in UML, read this. If you don't, you'll need additional guidance - this is not a "learn how to model using UML in 21 days" book.
And finally, a realization dawned during one particularly nice and sunny winter day: I really should blog more. It's not about being able to write more things for you to read, but rather about having the reason and the context to think and re-think the daily dilemmas in life. I spent years convincing myself that thinking is actually work at its best, and it's perfectly fine to spend time just milling things over (instead of producing an instant concrete result). Next I need to convince myself that thinking tools - such as this blog - are an equally acceptable way of promoting happiness and efficiency.
I'm going away on a skiing trip for a couple of days. Apart from the much-welcomed physical training it involves, getting out of town provides an excellent time to read. Into the bag goes, among others, John Grisham's Pelican Brief (many say it's from the worse end of his production, but we'll see), Writing Secure Code (2nd ed.) by Michael Howard and David LeBlanc. Oh, and of course, there's also the EOS 20D and a bit of photography literature - it's a good time to practice taking some nature shots.
The weather forecast says it's going to be a nice -10 degrees through the rest of the week, with perhaps slight snowfall and a few sunny days. In five hours, I'll be on my way to pure whiteness. Oh, I love Finnish winter. Have fun meanwhile :-)
To lighten up the Monday, here's a funny blog post by J. Michael Palermo: .NET - A Love Story. Anyone with decent OOP vocabulary can understand most of it :-)
Jason Mauss rants about clients who think they know something about web design. I agree with Jason in that web design in particular is a field where the bar for considering oneself an expert is considerably lower than for many other branches of business (say, architecture). It is obvious that the millenia-old roots of building architecture and the well-established formal education system award some prestige for those pros. A bit unlike web designers.
But that's not to say the respect for all the architects is always deserved - and unfortunately, many web designers are still worse. Even if you've "spent years in the trenches battling Photoshop, CSS, pixels, and HTML" doesn't mean you understand a thing about real design. Many web creators (deliberately avoiding the word "design" here) have wasted whatever respect the web profession may have had by producing abysmal sites that meet no substantial criteria for usability, scalability or maintainability. Any initial scepticism from the client's end is thoroughly understandable, and it is the pro's first mission to create an atmosphere of confidence.
In my books, requirements for a professional behavior includes, among others, the following points:
1) Know your field solidly (and know what you don't know)
2) Toss your ego and back up your opinions with facts and well-thought arguments instead of "I've been in the trenches, I know" crap
3) Evaluate the alternatives, even ones you don't initially accept
4) Think behind the words. The client may have stupid suggestions, but he often has a reason to bring them up. What is the reason and how can you cater to this need?
If you want be treated like a respected professional, don't just rely on your title - work to achieve the trust. Once your clients have confidence in you and your abilities, you will notice a sharp drop in the amount of criticism and wanna-be-expertism.
Ps. One of the more interesting parts of law studies is the theory on perfect court decisions. A verdict has to be legally sane and factually correct, but that's not enough. It also has to be convincing enough that even the losing party can understand (and hopefully agree) with the argumentation and reasoning. The court should never rely on people accepting the ruling simply because it comes from the court - not in the positively critical society we live in today. There's a lot to be learned from those thoughts, even in context very different from the judicial world.
As a totally non-professional note, I bought a Canon EOS-20D. What an excellent way to cut down the time spent with mundane coding affairs! Good or bad? We'll see...
Lately, I've read several interesting blog posts and news articles on the differences between open source and traditional closed-source commercial software. To mention three firestarters, here are some articles that led to me posting this: The Luxury of Ignorance by Eric S. Raymond, Judging the quality of open source projects by Ron Jacobs and now recently, How can I trust Firefox? by Peter Torr (this has to be one of the most commented blog posts I've ever seen).
Those articles are reasonably lengthy, so I'll summarize: ESR talks about the fact that open source projects often lack the UI design and customer-oriented thinking that f.e. Microsoft products have. There may be an easy-looking installation wizard, but it's actually incredibly hard to use. Ron says the quality of an open source project is very hard to measure, although it doesn't become quite clear why is it harder to measure than for traditional closed source. Josh Carlisle continues from Ron's post by outlining his suggestion on how to evaluate open source projects. And then, Peter Torr stabs at Firefox, pointing out several fundamental flaws in the installation procedure.
Where does all this lead? Now, on to my opinions...
The main dilemma left unanswered by the open source quality critics is, as already mentioned, that there aren't much better ways to evaluate the quality of closed-source products either. The fact that something is open source only gives you access to the source; that should, by definition, add to your ability of measuring the quality. Then again, OS projects vary heavily in stability; things like Apache and Linux are widely considered to be fairly stable and reliable, while many of the smaller projects are fueled by the enthusiasm of a few developers. Evaluating the sturdiness and health of and open source project may perhaps be even harder than it is for a commercial application.
Josh's blog entry outlines a "scorecard" for an OS project. While I don't believe in summing up the quality of a project by measurements such as "how many unit tests you have" (for obvious reasons) and "do you pass FxCop clearly" (FxCop's view of good code certainly doesn't represent a universally constant expression of quality), I agree this sort of measurements would aid both in development and in evaluating the software. Again, this particular facet applies similarly to all software. It would certainly be interesting to see the scorecard for, just as an example, Farpoint's Spread, one of the buggiest closed-source components I've had the pleasure to work with.
Many of the writers point out that an important facet for an OS project is its response to the actual (not just perceived, as ESR reminds) customer needs. Josh formalizes this to 'Average Time from Defect to Resolution'. Of course, the simplistic numeric evaluation of this is as misleading as statistics go - there are various good reasons to leave bugs unfixed, and good software management does not encourage rushing to every bug at every point. Still, the point is valid; support is fundamentally important for both OS and traditional commercial projects. Closed source vendors tend to provide more timely but also less useful support. "Less useful", because the coders aren't often using the code themselves on a daily basis, and because the release schedules often dictate the rate of fixes.
The category of "open source projects" is so broad that any conclusive statements are likely to hold for nothing but a meaningless fraction of all projects. Thus, it's perhaps best to focus on the more serious OS projects. In the same spirit, it's often not even relevant to evaluate the most marginal shareware components when you're looking at a commercial solution - you do want some stability. Between those groups, I believe some summarizations are possible. The following ones are, of course, my opinions only.
I believe the average code quality for strong open source projects is higher than for many of the serious commercial solutions. By "code quality" I refer to factors such as coding standards, security, unit functionality et cetera. So why do I believe this? I have a couple of main points here.
First, it is a known fact that time constraints and excessively tight schedules form a considerable quality risk. Open source projects have much less release pressures and thus enjoy the liberty of refusing bad-quality code. Again, this statement only applies for OS projects that have a notion of "release" instead of just tarballing random builds like some smallish projects do. Even though there are very professional and very quality-oriented businesses doing commercial software, I haven't yet seen the organization where the release pressure wouldn't occasionally cause bugs to occur. This happens in OS projects too - larger projects such as Mozilla approach the tightly scheduled release model of a business product anyway. However, the scale of the problems is considerably smaller.
Second, OS developers in serious projects tend to be very talented (as all of the referred blog posts also mention). They have often gathered much experience from business projects, but got frustrated by the lack of time and flexibility to do things "the right way" there. The OS projects are a way for them to practice their skills and polish their code to the extreme. This does lead to some excellent engineering solutions. It's often noted that the OS community also has beginner developers in their teams. This is true; but again, successful OS projects have and maintain the time it takes to review and correct the beginner's code prior to checkin. Most commercial product teams also get their share of beginners, but there's much less time and desire to educate them properly. Of course, there are vast differences between organizations here - best companies tutor their newbies better than any open source project could.
Third, the publicity of the code is a factor. We all know closed-source projects get some really ugly - and even risky - hacks thrown in as nobody will see them (this is often related to the pre-release panic). Open source projects can afford less of these, as the code is public and fame is pretty easy to lose. It's also much more personal - many open source projects have a very clear notion of who did and what. The personal responsibility of the product is on a level totally uncomparable to many of the commercial projects.
Fourth, open source projects are often more agile to adopt new architectures, methodologies and so on. They carry less burden from bureaucracy and policy issues. This is also supported by the ability to fork and merge projects more freely - developers and users have a much easier time trying out new features separately from the main installation, thus bringing together more ideas, more experiences and more alternatives than a single-path commercial application would do.
On yet another note: Code quality isn't as much a question of resources as one would easily think. In the end, it only takes one developer to write excellent code. He won't write as much code as a team of 50 full-time coders will, but he will probably write better code - just because he's alone, and the effort of coordinating different parts of the codebase are minimal. Of course, lonely programming isn't optimal even for code quality, but the same argumentation does work for team sizes (to a certain extent).
Most of the projects don't live just by their code. Measuring the code quality as written out above isn't the key factor for most product selection scenarios. When it comes to support, documentation, user interface issues etc., it's very rare to find an open source project to beat even the average commercial product. Now resources come into play.
If you're a coder, you can use open source tools pretty easily. In the .NET world, NUnit, NAnt, NDoc, SharpDevelop and CruiseControl among others are excellent examples of quite usable open source software - because you don't need much else than the code. Some of the projects even have decent documentation. But when you pick up Linux and OpenOffice and install it on a newbie's computer, you're in for a world of hurt. Although even OS desktop software has taken giant steps from its early days, very few open source applications can give their user the Luxury of Ignorance. When you don't have it, you need support and manuals. Too bad you often don't have them either, so you're screwed. Firefox has usability issues (even Peter's provocative post about the installation problems isn't entirely pointless), but it isn't from the worst end of the scale.
All this tends to tip the scales towards the direction of the commercial solutions. The closer to a newbie user you go, the more of the open source's bad sides you encounter. From the other perspective, the software companies' money (hey, you can actually get somebody to do the tech writing job the OS coders consider too boring) and the designated management / decision making system tend to produce more solid byproducts. Also, it is true that a commercial company may actually follow its customers' needs better than an open source project, where the key feature decisions are often based on the developers' personal needs.
Putting open source and commercial projects on the same line isn't easy. Even though these different categories of software origin come from very different backgrounds, they sort of compete. However, the open source movement isn't just another vendor. If you're lucky, you can take an OS project and use it just like you would use a commercial product. In these cases, the competition is fairly balanced. This works well for extermely well-polished OS projects (rather few) and the ones where you just need the binaries (many simpler code libraries, developer tools etc.). Normal home users naturally make their choice based on the product - for them, the development and maintenance philosophy rarely plays a significant role.
However, if you're making a bigger strategic choice, the playfield is much broader. An open source solution may not provide all the service you could get from a commercial product, but if you're ready to work some, you will also gain benefits you could never have from an external vendor. In a way, using an open-source product with an evolutive approach is a cross-over between using a shrink-wrapped package and writing (or having written) your own tools. This is the key part many organizations seem to ignore. Sometimes they have to, often they just don't think. The openness of open source provides the possibility to be your own tech support. That is not just a bad thing, even if it certainly requires some work.
The amount of the "well-polished OS-based projects", i.e. those ready to compete with commercial products, is growing. In the future, there will be increasing amount of choices to make. From what I have seen, I'd say the involvement of even one serious mid-sized company in an OS app's development can work miracles. Movement attracts movement, and suddenly you have a pretty nice team of developers maintaining not just their own code, but also yours. I've seen companies take use of Bugzilla in this way, and BZ is far from being the best example.
For business use, comparing open source apps with traditional software packages is like comparing the work of your own employees and the result of an outsourcing deal. Sure you can just look at the work results (did our offices get properly cleaned, or what does the software product look like?), but then you're ignoring much of the fundamental differences in the business model required (why did you go outsourcing anyway?). Deeper analysis is required for real results. Open source isn't always the winner - actually, it doesn't usually seem to be these days. But things are changing, and the scales are becoming more balanced. Again, good understanding and unbiased, honest evaluation of what's going on helps you benefit from the change.
Larry Osterman's recent blog entry gathered stories about a passed-away core Windows Multimedia developer, Syon Bhattacharya. I had never even heard about Syon before Larry's post, yet the memories and stories collected managed to impress me. My condolences to everybody who actually knew him. But allow me to publicly iterate some thoughts raised by Larry's post, as many things said therein jibe well with my recent thoughts on people in the IT business.
It seems Syon was a paragon of a truly dedicated hacker-spirit in the most positive connotation of the word. This is the type of person the IT world could use: the person who relentlessly pursues perfection in their field, but still does it in a spirit that benefits the end user of the product, the fellow developer and the IT field in general.
The problem is not lack of pursuit for perfection. We have plenty of that, even if the methods - or perhaps even the definition of "perfection" - may be suboptimal. Now, it's easy to guess my point: The problematic part is the "spirit that benefits [somebody else]" part. The selfish attitude is a growing problem, and it's further emphasized by the competitive spirit dominant in many companies (perhaps also fueled by the ever-increasing role of money as a work incentive). "Since information is power, it is not be distributed" - and this attitude alone ruins projects, not to mention human relationships.
Eric S. Raymond's old description of hacker attitude is a good start. However, the hackerisms described are a slippery slope. It's very easy to slide into extreme arrogance once you've become competent at something... An excellent start for a row of failures. While you may get away from it in an open source project with little direct social connections, real life jobs are another thing.
The business direly needs more people who not only understand the technology, but also can mediate between people from vastly different backgrounds. I'm not talking about meetings with salesmen, I'm talking about the developers, architects and project managers who, for example, get that new coder with Java-only competence into their .NET project and face the task of making the dude useful. Close-minded extreme focus on technology is a key ingredient in certain types of development, but most everyday programming tasks and teams benefit more from the open information sharing and supportive attitudes - which is, by the way, a surprisingly good substitute for bleeding edge competence on new technologies.
It's clear Syon was an excellent programmer - a programmer of a level most of us will never reach. Still, his kind character dominates the memorial writings over his significant abilities as an engineer. Since it's likely most of us will fade away with less respectable programming skills, wouldn't it be about time to focus on the character? Technical superiority is far from being the be-all, end-all target for becoming an excellent software developer. Social skills and the vibes you emit are far more critical in determining your true status. I think we've just seen a prime example.
A two week period of silence has passed since my last posting. So what has happened? Well, I could say both "a lot" and "very little". Very little in the sense that I really haven't had much time for discovering new things, twiddling with new gadgets, creating new software - or even the blog world. A lot in the sense that I've learned tons of interesting things, mostly from the work/organizational psychology sector. Bought a new TFT display. For work, I've seen a couple of delivery deadlines, some interesting development projects and a very quick business trip to Northern Finland (with an ATR-72 propeller plane, geez).
I downloaded the SQL Server 2005 December CTP, picked up a book about it and started toying. Unfortunately that also lead to an uninstall/install chain of various parts of my system, including VC# Express and VS.NET 2005 betas... Subtrivial to get all that stuff back working.
So my plans for the rest of the year?
1) Deal with a couple more delivery deadlines at work
2) Get that VS.NET and SQL Server back to a working state and start playing
3) Push out all the new code I have for JHLib (including unit testing and stuff)
4) Clean up my notes on setting up a Continous Integration server (CruiseControl) and post them here
5) Start an series of blog posts on some code quality issues
If I actually make three of them, I'm extremely happy. Looks like a busy christmas coming. :-)
Well, it's been a while since the last rant-style post, so let me de-pressurize myself some. :-)
Two incidents lately: One web designer half-jokingly stating "Non-IE browsers are for hippies". Another very open source -oriented freelance .NET software developer not remembering the name of Visual Studio and totally dissing the idea of using an IDE with a debugger - plain ASCII text files with Console.WriteLine statements rock! Even though neither of the speakers were 100% serious, both the comments had enough seeds of the true attitude to cause some agitation on my behalf.
If you're a home user of PCs, you can make whatever decisions on technology you want. You can ignore non-IE browsers, you don't really have to care. Want to close your eyes? Go ahead. If you're a corporate user, you may not be able to choose yourself - but rest assured, your IT department have made the choice. Like it or not, you usually have to accept their chosen technology and ignore the others.
On the other hand, if you work in the IT business, you need to think a bit more. If you're a Microsoft evangelist, slandering the Open Source without facts to back you up will no longer be credible. A Linux guru can launch a fiery burst of flame at Microsoft, but unless he can convince the audience with cold hard facts, he's likely to be a prophet only in the eyes of the fanboys - the choir who really doesn't need the preaching anyway.
Categorical statements about tools or technologies usually reveal the lack of knowledge involved. That's bad, because if you're in the business, you're expected to know. You're expected to maintain your expertise so that you'll be able to judge new technologies and products based on their merits. Any opinions, even rash ones, are acceptable when it comes to technology - the only criteria is that you have to have the balls to back them up.
With the rapid clip of development going on in most sectors of IT, it's very easy to close your eyes from the big picture. It's very easy to ignore Linux, Firefox, OpenOffice and other challengers if you work for a Microsoft-only shop like me. It's very easy to dismiss Microsoft's new products as marketing FUD if you're an Linux/PHP enthusiasts. The only problem is that the real clients and users in the world are having none of your nigh-religious fervor. They will still have the freedom to make whatever technology choices they consider fine in their perspective - and they will ask you why your web site doesn't work with their Opera, and what's the business gain in not integrating the code into a Visual Studio Solution.
It's all about credibility as a professional. Refrain from making overly broad statements about things you don't really understand. Nay, not just that. Refrain from being prejudicious. Wipe your head clean of non-factual suspicion. Be open. Learn more every day. Learn more about things you didn't think to be worth learning. Don't think you know everything because you know Linux/Windows/whatever and you're happy with it.
To sum it up: It's almost never a good idea to signal both prejudice and lack of competence, all in a single sentence.
Edit 2004-11-27: The third paragraph ("If you're a...") lost a sentence in my final edit of the post. After that, it made no sense and certainly didn't convey my original thoughts on the issue. Fixed it now; sorry for my carelessness.
My former position of New Media Manager at MikroBitti Magazine is now open, "only" three months after I left. For you Finnish-reading people, you can check out the job ad.
If you're a technologically competent IT project manager or a lead programmer/architect with interest in the magazine business and no fear for corporate politics and marketing, you might consider it. If you can take the stress and enjoy learning, it just might be fun.
In my world, I cannot avoid writing. Even if I could avoid blogging (hey, I'm becoming pretty good at it at least by view of the entry dates - not that I'd be particularly proud here) I'd still have to write a lot of stuff daily. Email, both in Finnish and in English. Code, of course - but that's not really writing. But then: documentation and meeting minutes, the bane of all IT workers!
Actually, I like writing them both, too. I don't expect anyone else to, but I have to wonder about the lax attitude towards them. Pretty often, I see professional developers, managers, consultants etc. produce really crappy documents. I mean people who I deeply respect because of their technical aptitude or attitude in general. But then, it isn't uncommon to be forced to spend two hours deciphering the vague scribblings from a one-hour meeting. Multiply by the amount of people who have to read the minutes... yes, that's really effective. Really.
Get to the point. Don't aim at excessive brevity; you're writing in a natural language, not C++. Use full sentences and flowing text (paragraphs) instead of bulleted lists with a few words on each line. Use proper headings to guide the reader about the structure of the discussion. Cover backgrounds if they're not obvious. Consider having all the information in an easy referable format (numbered lists or paragraph numbering do fine).
Why don't people spend time teaching themselves skills this basic? Why don't job interviewers ask about this? Why is it acceptable to have "Finnish: mother tongue" in your CV and get away with it, even if that mother tongue may actually mean really sloppy written command of the language? The point of this rant is not about people who can't write. It's about people who don't bother really trying. Documentation and meeting notes is not primarily a challenge for your writing ability, it's a challenge for your desire to your job well.
Every now and then I come across a situation where a person gets asked to do something, usually a work assignment, and he replies resolutely: "I can't". The voice inevitably conveys the lack of desire for the task. But what on earth you mean you can't???
Ability to do something is an interesting factor in human behavior. At worst, it goes like this: Unless you think you can X really well, you can't X. Not at all. If you're asked to X, you refuse. Well then, if you think you can X rather well, you're insanely smug about it. At this point, your skills aren't at the level of your bragging. If you spend some time with people who really know X, you probably degrade to the level of not being able to X at all.
Most of the people aren't really that bad, but surprisingly many make themselves look like clowns by making foolish statements on their abilities (or lack of them). But what's worse, people who stop at their "I can't" send out a really negative signal.
A book called The 12 Simple Secrets of Microsoft Management describes quite a few interesting management aspects from the Microsoft world. One of the key points is about recruiting smart people. There's an interesting paragraph on job interviews:
"The questions also search to see if the candidate can think. One of the old favorites at Microsoft was to ask how many gas stations there are in the United States. The interesting part was not the final answer, but how people went about solving it. Some candidates would give this question only 30 seconds of thought and then say they didn’t know. No further thought or attempt. At that time it didn't matter what else they could do. If they were incapable of turning on the brain, they were not good enough."
While Microsoft's recruiting practice certainly isn't a universal standard, it's safe to say that qualifying to work at MS means you'd probably qualify for most of the other tech companies as well. Regardless of any recruiting issues, "turning on the brain" is becoming more and more necessary as IT solutions get increasingly complicated. Saying "you can't" and stopping there essentially means you're going to perform routine tasks only. That's fine, but you don't belong in IT development then.
Spend some time on introspection. Learn to know what you can and what you can't. Keep people's impressions on a realistic level. If you're not familiar with something, say it - but don't let that stop you from doing your best. Few things are more motivating than lifelong learning.
Ps. Unless you already read JobsBlog at MSDN, I suggest you take a look. It's written by a couple of Microsoft recruiters and provides pretty interesting insights into tech jobs world. Again, from a Microsoft perspective only, but much of the psychology applies for everyday life even outside the IT world.
If you're a web developer, you'll definitely want to browse through Microsoft's document of browsing-related changes in XP SP2.
For starters, there is the IE popup blocker. Popups will be allowed if opened by a link clicked by the user, but other than that, no more JScript window.opens for untrusted domains. By the way, a likely side effect is a rush towards interstitial advertising ("you will be redirected to the requested content after watching these ads for 5 seconds") as popups start losing their effect.
An equally drastic change is the new set of limitations on popup window size and positioning. Popup windows can no longer extend above the top or below the bottom of the parent control, and they must overlap the parent window horizontally. They will stay with the parent window if the parent moves, and they will always appear above their parent windows - so no more hiding or faking dialog boxes. I'll just quote some of the most important other rules:
"Windows that are outside the viewable screen when they are opened are positioned onto the viewable area."
"Windows that are larger than the viewable screen when they are opened are resized to the viewable area."
"Scripts cannot move a window off-screen"
"Scripts cannot resize windows such that the title bar, address bar, or status bar cannot be seen."
"When creating a window, the definition of the fullscreen=yes specification is changed to mean “show the window as maximized,” which will keep the title bar, address bar, and status bar visible."
"Internet Explorer has been modified to not turn off the status bar for any windows. The status bar is always visible for all Internet Explorer windows."
In addition to popups, security zones have a bunch of new tweaks thrown in. Add-ons can be easily disabled. And to introduce another breaking change, "the Internet Explorer will now attempt to rename downloaded files in the Internet Explorer cache to have matching content types and extensions to protect against files that mislead the user about their type."
Most of the changes are pretty irrelevant for legit applications, but in case you had a web UI that was designed to be shown in a small window and then open up image thumbnails (or news articles or whatever) in a larger popup, you're probably in for a redesign - preferably a quick one. Another likely breaking scenario involves quirky webmail apps relying on setting MIME type to application/octet-stream to force download (instead of inline opening) of attachments.
It'll be interesting to see the amount of web apps that'll blow up when SP2 starts spreading. And it feels so good to have Firefox installed. :-)
Short and sweet: Windows XP Service Pack 2 is out. Here's the lengthy list of changes and here's some documentation for developers.
MSDN Product Feedback Center Blog explains how bug votes and Dr. Watson reports affect bug priorities inside Microsoft. The story discusses the differences between "this is important for me"-style vote (0/1 votes) versus the current MSDN style (where you can give a bug an importance score of 1..5 - or a 0-x voting system from a more generic perspective).
The aim of both approaches is to get a community opinion on which bugs are the most critical ones. Dr. Watson's error reports (just like f.e. Mozilla Quality Feedback Agent's similar ones) act as 0/1 votes - either a user experiences a crash or not. So, for crash bugs, Watson measures the amount of occurrences in the user base. For non-critical bugs, a good measure is harder to find, since you usually cannot get automated problem reporting.
A 0/1 vote on bugs is slightly problematic, because sorting by the vote count doesn't really tell you about the severity of the issue. An enhancement request to a really visible part of the product can bypass a dataloss bug in a less popular module. Even if you trim out enhancements requests (RFEs), you're still left with a pretty flat view of purely quantitative measurements.
The bad part here is that a 0-x voting system is usually no less troublesome. While you do get qualitative opinions on the importance, they're likely to be misleading. Most normal people vote maximum importance on any bug they've encountered regardless of its objective severity. A particularly serious bunch of reporters can probably constrain their voting habits a bit, but with big publicity products 0-x voting easily degrades into a 0/5 system.
Don't believe that? Go to PFC and search for bugs reported in last couple of days, filtering by "rating 5". As a result, I noted that 33 of 88 bugs are of rating 5. Sure, at least 20 of those drop from the 5.0 rating because somebody else considers them irrelevant and votes 1 - but not all of them. People aren't very active at downvoting reports they don't consider important, even though (at least theoretically) the best way to make your own bug report stand out would be to vote 1 on every other report.
Eventually the system ends up with numerous irrelevant reports at the top of the list, and loss of confidence in the whole rating system. How about filtering by vote count then? Sure, but you'll be losing information _and_ gathering a base of rating 5 bugs which you'll never see on your radar. Doesn't really look good from a customer perspective.
Oh all right, I'm pretty pessimistic here. Still, past years have strengthened my belief in one model: 0/1 voting and an easy way to post verbal comments. You'll get whining ("Fix this, it's the main reason my friends won't use X!!!"), but the freetext entry also gathers the most informative views and the best arguments - that's far more effective and credible qualitative analysis than a 0-5 vote. It's harder (less automated) for the developers, but definitely better for the product.
The last few days have been nothing short of hectic. It was to be guessed, though: Final tasks at the old job, preparing for the new one. My medium-scale farewall party was fun - and included a monster-scale swiss schnitzel (in-baked with ham, cheese and feta - and yes, those two are lemon halves). And after this one day of rest, it's time to start all over again, in an organization I barely know, mostly working with people I have never even talked to, doing things that are familiar to some extent, but nevertheless pretty different from what I did before. Well, at least it's a challenge.
But the relentless flow of IT news doesn't pause simply because I'm busy. There's a good deal of new, interesting stuff to delve into. From the top of my mind: Comega (some call it C# 3.0) compiler preview, Dundas Chart 4.1 beta, Bugzilla 2.18rc2... Uh.
So what's going on here? It's Jouni's blog about IT stuff, mostly coding-related. The history of this content stream actually dates back pretty far; I've published my writings more or less regularly for several years now. Since my other blog (Lakiblogi, in Finnish only) became focused on law issues only, I was left without an easy publishing channel for this sort of things. The apparently growing role of IT and coding in my life is another reason for doing this now.
A short introduction is in order here: I'm Jouni Heikniemi from Finland, 25 years old at the moment of writing, and working for 1,5 weeks more as the New Media Manager for MikroBitti Magazine. Starting from 1st of August, I'll be working at Blue Meteorite Ltd. as a software architect. By heart I'm a .net man, but we all have dark sides in our character: I'm also one of the core developers of Bugzilla, The open source bug tracking solution (and damn, it's written in Perl!). Outside of the IT world, I'm a law and CS student at the University of Helsinki.
I'm not the guy who lives his life on the blog, so you're not supposed to expect a steady flow of postings about my vacations, relatives and life in general. I write when I have something to say, and usually for the purpose of conveying some tidbit of information. Oh, and why English instead of Finnish? Well, why not - everybody in the IT field will be sufficiently adept in English anyway, and this is one way to make the archives useful for a wider audience. Besides, it's good practice.
Without further ado, welcome!