work/career

Why Things Don’t Work In Your World

1 Comment »Written on May 13th, 2012 by
Categories: work/career

A very common reaction for developers to have when they hear about new technical approaches or new approaches to team organization is "yeah right, that won't work in the real world" or "that'll never work in our situation". A lot of us have felt that way. I certainly have as well a few times in the past. The 2 most common excuses you'll hear for not believing something can work are:

  1. The people I work with aren't good/talented/disciplined enough to make this work.

  2. It can't possibly work in our organization.

The truth though, is that it's actually because of you. Whenever you say "that won't work for us" or something similar because of the people you work with, you immediately show your lack of faith in them. You might think that that lack of faith is justified, but that basically means you've given up all hope of making things better. You know it, and worst of all, they know it too. People who aren't trusted by their coworkers or superiors generally pick up on that rather quickly. Some of them will respond by putting in more effort and trying to do better. Others will become demotivated and wonder why they should even try because "it's never good enough anyway". At this point, your lack of trust in your coworkers becomes a self-fulfilling prophecy.

You might want to consider another approach. Think back on how you've responded to situations where you where challenged by coworkers or superiors but where it was clear that they trusted you and believed that you were capable of doing a better job. I'd bet that for most of you, it improved your motivation and your willingness to do better. It probably helped you bring out the best in you. You can use this to your advantage when you're trying to get better results out of your coworkers. It's quite simple really: it's all about how you approach someone. If you want somebody to do better, and you approach them in a positive manner you're much more likely to get better results. If however, they sense your distrust (and most people pick up on that quite easily), they will most likely be defensive or apprehensive. The odds are quite low that something good will come out of that.

If you want people to improve and do better, it's important to establish a culture where everybody knows that it's ok to make mistakes, and that every mistake is an opportunity for the whole team to get better. If that's not the case in your situation, what is preventing you from trying to get to that point? Even if you're not officially in a leadership position, there's no reason why you can't set the tone and be a leader. Start making an impact on one or two people and build off of that growth. Once you've got a few people convinced, it's much easier to bring the rest along with you. You don't need to shoot for the stars from the beginning either. Try to improve whatever it is you think needs improvement with small steps, in an iterative approach. Instead of thinking "that will never work for my team", think "we're not quite ready for that yet, but we will be someday".

If you believe you can't improve your way of working due to organizational reasons, it's important to also start with your team. It's easy for management to ignore the opinion of one person, but it gets progressively harder for them to ignore it as more and more people start asking for change. It's much easier to persuade management to try something new if you can show that the whole team believes it's worth a shot. Keep pressing the issue until you get the chance to try it for a short time. If you keep asking for it, management might just get tired of hearing it and who knows, they'll grant you some time to try it out. You'll never know if you stop trying.

Of course, you won't always succeed in convincing management or your coworkers. But you've gotta try. And if you keep hitting walls, you might actually be better off moving on to another job with other people instead of being frustrated in your current position. Even if you don't agree with what I'm saying in this post, you can't possibly disagree with this: not trying will get you nowhere.

It’s Not About The Number Of Hours You Put In

8 commentsWritten on April 19th, 2012 by
Categories: Opinions, work/career

There's been a lot of talk on twitter about the 501 Manifesto. Be sure to read it if you haven't, because it's got some very good points, though I don't like the dig at people who contribute to open source since these people are having an ever increasing positive impact on our jobs. Anyways, the manifesto is about being a software developer without being defined by it. I actually think it's a healthy point of view.

I've always disagreed with this seemingly popular point of view or opinion that every developer should spend a lot of time outside of his/her working hours blogging or publishing their code on Github or contributing to open source. Those activities can be important but aren't necessarily so and the people doing them aren't inherently more valuable or important than developers who choose not to contribute to open source software or who don't feel the need to make a name for themselves. I also disagree with the notions that developers who are only involved with software development during their 8 working hours a day must be inferior or that they can't be passionate about it or that they'll never be great at it or any of that other crap that you'll sometimes hear people say.

I know some great developers who put their code out there and/or their thoughts by blogging. I also know some bad developers who put their code out there and/or their thoughts by blogging. I know some great developers who aren't involved with software development outside their working hours. I also know some bad developers who aren't involved with software development outside their working hours. There are good and bad developers on both sides of every situation you can come up with.

I think it depends a lot on what people do during their 8 working hours. Can we really say that developers who work 8 hours a day on challenging projects with strong co-workers in teams where knowledge is passed around continuously are missing out on anything if they don't really spend any other time on software development outside of work? That just doesn't make a lot of sense to me. If I look back on my own career so far, I've typically been rather passive outside of working hours in periods where I felt like I was working on cool things, where I was challenged, where I was learning a lot on the job. Conversely, I've always been much more involved with software development outside of work when I was working on things during working hours that I didn't find challenging or interesting or where I wasn't learning anything new. I'm guessing that this holds true for a lot of people, though certainly not all.

Of course, if you're not working on interesting things or continuously learning and improving on the job, it's your own responsibility to make sure that your skills and insights stay up to date. You don't have to put in the effort to do that, but if you don't, you don't really have a reason to complain either when you're not happy with the kind of work that you're doing. Your employer is not responsible for your career and your future, you are.

And if you are working on interesting things and continuously learning and improving on the job, you don't need to pressure yourself to do more outside of your working hours because certain people in the community say you should. A lot of people get involved with blogging and open source with the hope that it'll end up leading to more interesting work in the long term. Who knows, you might just be a step ahead of them already.

Most Valuable Professionals? Give Me A Break.

29 commentsWritten on April 15th, 2012 by
Categories: Opinions, Rants, work/career

I've always been very skeptical of Microsoft's MVP award. Officially, Microsoft's MVP award stands for Most Valuable Professional, but its true meaning is probably closer to Most Valuable Promoter. The quality and integrity of the MVP's you know is probably dependent on the region in which you work. I work in Belgium, and over here the MVP program is, in my opinion, a joke. I'm going to discuss why I think it's a joke but keep in mind that this will depend on your region. I know that there are indeed great MVP's out there who do have professional integrity and true real world experience in some regions, but I certainly wouldn't be surprised if the state of the MVP program in Belgium occurs in other regions as well.

First of all, let's take a look at an image that Microsoft uses on its MVP page:

MVP image

"Independent Experts. Real world Answers."

This is indeed what the MVP program should be about. It is however the exact opposite of what I and many others in Belgium have experienced. Let's cover the words in those 2 sentences a bit more in-depth.

Independent

Most of the .NET MVP's in Belgium work for a handful of companies that happen to be big sponsors of every important Microsoft event in Belgium. Now, could it be possible that the best .NET developers in Belgium all work for these handful of companies? I highly doubt it. I know a lot of great developers in Belgium and none of them work for these companies. And I'm quite sure that none of those people are less valuable or knowledgeable than any of those MVP's. In my experience, there is hardly anything independent about the Belgian .NET MVP's. Most of them got their first MVP award while they were employed by sponsors or 'strategic partners' of Microsoft. Most of them tout the latest and greatest Microsoft technologies, pretty much unquestioned, even if it means contradicting their statements and positions when they were promoting the technology that Microsoft wanted them to promote 3 or 4 years ago. And they're never openly critical of anything Microsoft-related out of fear that it will negatively impact their chances of being renewed as an MVP. They may not work for Microsoft, but they are anything but independent of Microsoft.

Experts

This is a tough one. What makes one an expert? In some fields, people are considered to be experts based on the amount of research they've done. In other fields, people are considered to be experts based on what they've actually done. I don't think I'm going out on a limb here by saying that in the field of software development, what you've done should be more important than what you've researched or read about. In my opinion, an expert in a specific technology should have built at least one, and ideally more than one, non-trivial system using the technology in question and should be able to tell you about mistakes they've made, things you should avoid, and should never use examples that promote bad practices. I rarely hear MVP's talk about things you should avoid. I rarely hear MVP's talk about mistakes they've learned from. I routinely see examples from MVP's that make me cringe. I routinely hear MVP's promote technologies even though they haven't actually built anything impressive with it. I think of a lot of words when I see examples or proposed solutions by MVP's, but the word 'expert' unfortunately isn't one of them. This also applies to the Microsoft Extended Experts Team by the way. I can only question the validity of such a team if it contains people who are listed as experts of a particular technology when I happen to know for a fact that some of those people have never even used the technology they're supposed to be an expert in in a real world project. Let's be honest here: most of the MVP's and the MEET members simply aren't experts. They are people who have a strong interest in a particular (or more) technology and do their best to promote said technology. There's nothing wrong with that at all, but there's a huge difference between that and being an expert in something.

Real world answers

This one cracks me up the most because most of the Belgian MVP's hardly work on real world projects. And when they do, they typically work on "multiple projects" as they like to say it. For anyone who's ever worked on multiple projects at the same time: could you honestly say that your contributions were truly valuable to the end result? Let me put it differently: don't we all know that people generally produce the best results when they don't have to juggle too many things at once and can focus on as few things as possible? You will rarely hear about a Belgian MVP working full time on a non-trivial real-world project. A lot of them get to spend a certain number of paid hours each week on 'community work', which means blogging, writing articles for magazines, creating presentations for events, etc. When they're not working on that, you'll often find them talking on Twitter about pretty much anything but interesting or demanding work. And of course, their employers will occasionally send them to clients for a bit of consulting here or there, or to do a product demo. Unless these guys are putting in 60 to 80 hours a week (which I seriously doubt), I'm having trouble figuring out when exactly they do the kind of interesting work on real world projects that would enable them to provide answers based on real world experience.

It also doesn't help that I've frequently heard rather unflattering stories about these MVP's from people who've worked with them. It's pretty much always the same: they're not invested into the project, they spend too much time 'interacting with the community' and if you let them go near important parts of the code base, bad things usually happen. Now, I'm not the type of person who simply believes everything he hears. In fact, when it comes to matters like these, I generally only believe the stories I hear from people of whom I'm truly sure that they know what they're talking about. And if you've been reading this blog for a while, you'll know I'm rather critical and that I set the bar rather high when it comes to that.

Lastly, my personal working experience with MVP's has been abysmal as well. I once worked for a client where we had to get rid of 2 people because of how bad they performed in real world circumstances. One of them was an MVP at the time, and now works at Microsoft as an Evangelist. The other wasn't an MVP at the time, but has been one for a few years now and is even one of the Regional Directors of this region. A few years later, I had drinks with a manager of the company they both worked for and he bluntly admitted that both of them are useless on real projects but that their MVP status was a huge benefit to the company from a marketing and image perspective. Not exactly the image or branding I'd be looking to put out there, but hey, to each his own.

Why On Earth Did I Write This?

For 2 reasons. I think this whole MVP thing sets a bad example to young and impressionable developers who aren't sure what to focus on to advance their careers. To outsiders, these MVP's sure look like they've got a great thing going and it's easy to see how that could impress people who don't know better. There are already quite a few developers who suck up to these MVP's in the hopes of someday getting to 'that level' as well. I'd much rather see these people put effort into learning about concepts that will last them a long time and building skills that are transferable to multiple technologies instead of sucking up to the wrong people, and trying to network their way to more interesting work because the work that results from that is truly mediocre at best. By all means, try to make a name for yourself by blogging and speaking publicly. But do yourself a favor and stay true to yourself and favor quality over quantity when considering the audience you want to target. Hey, it worked for me :)

The second reason is because this whole MVP thing is, in my opinion at least, offensive to the many dedicated professionals who give their all at their jobs as they work on real projects that matter, as they try to mentor younger developers in their workplace, as they try to optimize the way they develop software not only for themselves, but for their teammates and their employers or clients. These are your true valuable professionals.

I'm sure I'm gonna get a lot of flak for this post, but honestly, it won't really make any difference to me. The people who'll be offended are people I'd rather not work with anyway. And of course, I feel quite confident that I'll rarely, if ever, have to deal with these people in a professional setting since I'm primarily interested in interesting and demanding work :)

Thoughts On Learning New Things

8 commentsWritten on March 11th, 2012 by
Categories: Opinions, work/career

Jef Claes published an interesting post about his preferred way of learning new things. There's one part in the post that I don't entirely agree with:

I like to believe learning should be a hands-on activity as well. Basically, stop consuming, start producing. Don't get me wrong, I do think there is value in reading blog posts (I might be slightly biased on this one), reading books and watching videos, but I find that this value is marginal compared to what you gain by actually doing it.

Hands-on activity (producing) is certainly a very important part of any learning process, but I wouldn't go as far saying that the value of reading books/blogs (consuming) is marginal compared to that of producing. In fact, I believe their value to be pretty equal. I've seen too many people who start producing simple things, and then think they've got a pretty good grasp of the technology they're using and then move on to producing more complex or bigger things without actually knowing enough of the technology they're using to support the more complex or bigger scenarios. The results certainly aren't always pretty and I'm sure each and every one of you has seen this scenario unfold with at least one developer you know. Probably more than that even.

I think in a lot of cases, people start the producing phase perhaps a bit too early and then in their enthusiasm of seeing things working sort of skip the more boring consuming that could've benefitted them a lot. Once you've started producing, you need to keep consuming regularly. A tremendously valuable part of any learning experience is getting feedback and insight from minds that have more experience with a given subject than yours. If you're lucky, you can get this from your coworkers. If you're not that lucky, you'll need to find other sources and books, blogs, videos, user group meetings, etc can be a great way to fill that void. And even if you do get to learn a lot from your coworkers, it never hurts to learn more from the experiences of others outside of your immediate circle, if only because their situations and constraints will differ from yours as well.

The other very important part about consuming is really getting to know the technology you're trying to learn. I've always found it very important to at least get an idea of how things work internally within a technology that I'm using. You certainly don't need to know all of the implementation details but just having an idea of it can really help you avoid a lot of problems once you need to use a technology in a more advanced way than in your initial experiments. Most importantly, it should give you better insights as to whether you're using the technology properly, which unfortunately isn't always the same as getting something working. And as a bonus, you'll probably learn about features you won't immediately need but knowing that they're there can save quite a bit of time and effort later on. Just imagine the improvement of the signal-to-noise ratios that you'd see on mailinglists, forums, and StackOverflow if everyone took the time to get a better grasp of the technologies they're using.

When I start with learning new libraries or frameworks, I usually start off by reading most (and often, all) of the official documentation of the technology before I even get into building something myself. If I want to learn a new programming language I'll look for the most recommended books for that language and buy one (or more, if I wasn't satisfied with the first one). I won't even start using the language until I've gone through the book. Once I feel like I've got a pretty good theoretical grasp of the technology, I start building something with it. I also start looking for good blogs on the technology and subscribe to them. I'll also start following influential people of the technology on Twitter. And I just continuously try to soak up as much knowledge as I can from people who're doing more impressive things with the technology than I am. At first, you might not understand everything they're talking about but after a while, things just start clicking and you're getting a really good grasp of things. None of this is a substitute for learning from producing, but it certainly is an incredible addition to it. And one that makes a world of difference, IMO.

Faster Hardware? Not On Our Budget!

10 commentsWritten on November 8th, 2011 by
Categories: Software Development, work/career

A lot of developers working in enterprise environments are used to not getting the right hardware that would make them more productive. You know how it goes: Operations likes to 'standardize' the hardware that gets rolled out and in too many cases, no exceptions are made for developers. Which is a shame, really.

The simplest, and probably most effective example is that of giving developers SSD's instead of regular disks. I'm willing to bet that using an SSD instead of a regular disk could save an hour of lost time per day, per developer on average. Suppose the hourly cost of a developer is 80€. Now suppose you have 30 developers in total. That would be waste of 2400€ a day. Now suppose you have to buy 30 SSD's at 300€ each, which would set the company back 9000€.

That 9000€ investment will have paid itself back after 112,5 man-days, which is only 5 calendar days if you have 30 devs. After those 5 calendar days, the investment starts reducing development costs with 2400€ a day (on average), which for a full year (using 220 working days) could result in a yearly saving of 528000€ for the company.

Of course, Operations is usually a separate division from those that are responsible for development, which means that they have a separate budget sanctioned for what they need to do. Now suppose that Operations has to spend about 5000€ per year to replace failed SSD's. And lets assume that the yearly support cost for those SSD's is 20000€. I pulled that number out of my ass, which unless I'm mistaken is standard operating procedure whenever an Operations division gives you an estimate of support costs. Anyway, it would mean that on top of the 9000€ investment, a yearly recurrent cost of 25000€ would need to budgetted. And for what? The Operations division can't demonstrate a single benefit for their division to justify the cost.

Nevermind the fact that the company would save about 500000€ a year...

« Older Entries

Meta

Recent Posts

Categories