Friday, October 12, 2012

Time for a change

I've been considering this for several months and now got an opportunity to make a change. This post describes my next career move and why I decided to do this.

The history

The past four years I've been working for a software company that builds a product suite around Human Resources and Salary. The suite contains anything from salary calculation and HR registration to Employee and Manager Self Service systems. I was hired to help bring innovation and new technology to the existing team and work on the next version of the product.

As you might know we started with Silverlight 2 beta shortly after I joined the company. We worked on this product and upgraded it all the way to Silverlight 4 in two years time, until we decided that we needed to move away from Silverlight. For the past months our team has been working on delivering an ASP.NET solution.

My role has been to lead the team from a technical standpoint and architect the framework underlying the application. I've been happy to do this, however I still decided to change.

The Why

There are several reasons, some of which I'm not comfortable to discuss online, however the most important ones I can discuss.

The first reason, to me, is inherent to the assignment I had. If you complete the assignment, in this case developing a framework and getting a team up to speed on using it, you can't help but ask "What's next?". Unfortunately the answer was, "Finish the rest of the product." To me, this didn't (and still doesn't) sound very appealing. If you've been working on highly technical generic code and all of a sudden you're expected to do repetitive development, somethings got to give.

The second reason is more personal. I find it important to keep improving myself and I didn't see myself being challenged enough to improve on the skills I think are important to improve on as a senior developer, mainly soft skills. At some point you can get to comfortable in a certain situation.

The What

 So the final question is, what am I going to do? I've though about this and figured that in order to improve on soft skills a more customer facing role would suit my ambitions better. As I still wanted to be doing technical work as well a consultant role was the obvious choice. However I didn't want to be working with just another 'hour-factory' where you're just expected to bill as many hours to a customer as possible and I didn't feel much for being just another SharePoint 'specialist'.

I've been looking around and thinking about different routes to get what I'd like until an opportunity came along that I really liked. As of October 15th, I am working as a Senior Consultant in Enterprise Search. I've been working with enterprise search technology between 2004 and 2008 and I enjoyed it very much and always did want to go back to it and now I got the chance!

So what does a consultant in Enterprise Search do? I'll be working for customers that want to use Autonomy technology within their organization. Assignments can range from a simple advice all the way to a complete one off implementation for the customer. I'll be working multiple projects at a time and I'll be working with different programming languages and platforms a long the way.

So what about Developers 42?

What does all this mean for Developers 42? I will try to continue writing posts as time passes. However it does mean a change in direction for the topics I'll discuss. As I'll be using multiple programming languages, chances are I'll be writing more about my experiences with those.

Further more, as I explore more of the world of Enterprise Search and it's surroundings, I might be able to give some insight into what goes on in this field of expertise I'll be a part of once more.

I do hope you'll still be following this blog and to learn and teach together with you.

Follow me on twitter as well.

Friday, August 10, 2012

To Tweet or not to Tweet. That’s the question.

In this post I’d like to give an explanation of why I decided to start using Twitter and how it has worked out so far.

“Why on earth do you think you need to write a post explaining why you started using Twitter?”, you might ask.

I don’t like social networks

Well, people who now me, may have learned that I’m not a great fan of social media. I tried using several and most of them still don’t seem to add value for me.

Especially a network like Facebook appears like a serious waste of my, and others, time. I do have a Facebook profile, but I mostly use it to promote my blog posts.

The main reason I don’t like social networks is because I think most of us don’t have such an interesting live that you need to post updates about it every five minutes. Does anyone really care that I get up in the morning, go to work, when I drink coffee and when I go back home? Another question is, do I want others to know when I go to work and when I get home? To me it’s all a lot of noise and I don’t feel like spending time creating that noise for others to listen to.

Why Twitter might be different

So why go and use Twitter then? It seems like a lot of noise. Two things occurred to me. First of all, not a lot of people in my personal network actually use Twitter, so I don’t feel obligated to actually follow tweets by people that are close to me. The other thing is, and that applies to all Twitter users, Twitter is unique in the sense that it’s not automatically two way traffic. I can follow someone, but that doesn’t mean that someone will follow me.

This means that I can follow people who I think might have something interesting to say without me worrying about being intrusive and it also allows me to not follow a follower who I think is unlikely to tell me something interesting.

Besides the advantages of the platform I saw, I was looking for a platform to get some more interesting information about what others are doing in the field of software engineering.

I was also looking for a platform to promote this blog a bit better and a platform that allows me to post short updates appeared to me as a good way to do that and a challenge in the process. As some of you may know, I’m not blogging at a preset frequency. This does mean you may not hear anything from me for months. The reason for that can vary from being to busy to write something worth reading up to just not having a topic worth writing an entire post about (then again, maybe writing a post about why I joined Twitter might not qualify as a topic worth writing a post about Smile). With Twitter I can just write a one liner, share a link or a thought and it’s done.

Experience so far

So what has been my experience up to now? Well, I don’t have any real followers, so I don’t know about noise to others. I did tweet about ten times now of which two were retweets. I did find several Twitter accounts to follow that provided me with interesting Tweets. I got to some information I wouldn’t have got if I wasn’t on Twitter. I also stopped following some accounts as they provided me with to much noise. All in all that makes it meet my expectations.

This is another thing that struck me on Twitter. It seems more natural that people stop following other people. I had a follower and she stopped following me after about a day. I don’t know why and to be honest it doesn’t really matter. I see it more as a long running conversation. Once it stops being interesting for one of the parties involved, they leave the conversation. It makes sense to me.


So I have joined Twitter and up to now it has been a reasonable experience. I will continue to use Twitter for the upcoming months. If you think I might tweet something interesting, or if you want a tweeted update whenever I post something here, please join me on Twitter: @jvandeveen.

Feel free to share your experience with Twitter or other social media in the comments section below.

Tuesday, July 31, 2012

A TED video I think you should watch

In this post I would like to share a video from TED, that I think anyone even remotely interested in computers should watch.

Every now and then I like to watch videos that teach me something and/or inspire me when it comes to innovation. I used to limit myself to Channel 9, which is a great source for anything even remotely (and sometimes not) related to Microsoft. It has been inspiring and educational. Remember this post I wrote back in 2009?

Last year I was pointed to TED. As TED says on their website, they are a ‘nonprofit organization devoted to Ideas Worth Spreading’. Find out more about TED here. You should note that most videos on TED are presentations or talks. Sometimes there are interviews and sometimes there is a video with some kind of performing art.

The video I’d like to share with you is this one. It is a talk by John Graham-Cumming and it’s about the first ever design for a computer by Charles Babbage. I don’t want to give you to much information on the details, but you should definitely watch it. It’s only twelve minutes long, which is a common thing about these talks, they usually are not very long, which makes it easier to find the time to watch some of them.

One thing I took away from this is that although it is ok to doodle around with a whole bunch of different ideas, we should every now and then execute one of them.

If you have other great places where you find inspiring and/or educational videos, feel free to share them with us in the comment section.

Tuesday, May 29, 2012

Innovation can't be planned

The profession of software developer is a relative young one. As such we learn new things about it that other professions already have figured out. This post is about one of those things that managers who need to manage developers rarely seem to get: innovation.

Software development is devided in two different types of work, the standard projects for which you can simply apply well known en documented methods that lead to a predictable result, and the innovative projects where features and requirements can change based on the technical possibilities and impossibilities.

For example, implementing a corporate intranet in a CMS is well understood and tends to be predictable. On the other end, building a new product where the UI has to be available on a wide range of platforms and devices is not only new, but also has numerous variables that make it different every step along the way. Sure, there are methods to execute a project like that in a structured way.

Most agile methods appear to be suited to do highly innovative projects. However, they do have a single flaw, which I've recently experienced. Although they do allow for great flexibility in the big picture, once it comes down to the detailed work, they don't allow that same flexibility because at some point there still has to be some predictability so it can be sold to managers and executives alike.

In practice, when using an agile method, developers are still required to commit to delivering a certain amount of work within a certain amount of time. The only thing that has changed is the amount of work they are asked to make an estimate for. It's like instead of asking to design and build a spacecraft you're now asking for only the propulsion system. Sure, it's less work, but it's still highly unpredictable, especially when you find out the maximum speed in the specification is not nearly enough to get the craft to the destination within a reasonable amount of time and the fuel consumption needs to be cut in half.

Obviously the example above is exaggerated, but the point is that with innovation things can only become apparent once you're working on it. You encounter problems you could not have thought of and you have to solve them in order to deliver a product that's up to standard.

So how do you go about building an innovative software product? The first thing is to make sure you have the right people leading the team and trust them. Also make sure there is a clear set of boundaries that the team needs to operate within. Then support them and facilitate their work as much as possible.

This doesn't mean you can not put a timeconstraint on a project. However if you do, you should be prepared to compensate for that in functionality (some would argue that you can also assign more resources to a project, but why I think that has great limitations is a topic for another post).
So please, stop trying to plan your innovative development as you will only be disappointed.

Friday, May 18, 2012

Writing code != developing software

There has been some fuzz online about whether or not should everybody learn how to write code. In this post I’d like to add my point of view and take into account what the profession of developer involves (or should involve).

If you have not followed this discussion, you might want to read up on some other posts firsts:

Please Don't Learn To Code - Jeff Atwood

Please Learn To Think About Abstractions - Scott Hanselman

In a nutshell the fuzz is caused by public figures announcing they are going to learn how to write code.

The car mechanic

There has been several comparisons with other professionals already. However I think they are not really suited for what is happening here. I like to explain why learning how to write code doesn’t mean anything by projecting this to the profession of the car mechanic.

Let’s say I announce I’m going to learn how to work on an old car engine. If you analyze the skills I need to work on a car engine it almost becomes laughable:

  • I need to be able to open the bonnet of the car
  • I need a basic understanding of tools in the toolbox (a spanner, a screwdriver, etc.)
  • I need to be able to start the car and drive it in order to test my work

Anyone can see that it I work on a car engine with only the above skills, I’m very likely to ruin the engine. At the very least we can conclude that being able to work on an old car engine doesn’t make me a car mechanic.

Let’s project this example back to the software developers profession. If you want to write code you need the following skills:

  • I need to be able to install and run an IDE
  • I need to be able to type code in the syntax for the language I’m using
  • I need to be able to use the IDE to compile and/or run my code

If you are going to use only the above skills to write a program, changes are you are not going to achieve the results you want. In any case the above skills are not nearly enough to become a software developer.

The software developers profession

Jeff Atwood makes an excellent point in his post when he states that being a software developer is not about writing code, but about solving problems. I completely agree with Jeff on this point. If you read the post he refers to when making this point (here), you’ll see he paints a very bleak picture about developers being extremely disconnected from the users they are building software for. I personally do not have that experience, but then I’ve always worked in relatively small teams (six developers being the max).

In my career I’ve coached several developers and I’ve always been an advocate of what to me is the single most important skill any developer should have is the analytical skill. I’ve even given short trainings in analysis. When another developer asks for my help solving some problem, I always try to be very verbose on how I get to my analysis.

And as Jeff Atwood also states in his post, writing less code is better. In order to do that, being analytical about what you’re trying to achieve is crucial.

Obviously you can have all the analytical ability in the world, but if you don’t have a proper understanding about what you’re dealing with, it being the inner workings of an operating system, or the politics around some customers feature request, you can not make a proper analysis. This means you do need knowledge.

This brings me to a problem that is fairly unique to the software developers profession. Code is not knowledge, however it is transferred and documented online in vast quantities. This has created a whole breed of so called developers who simply go online and copy code for what they think solves a particular problem they’re having, without actually understanding what the code does, nor why they are having a certain problem. The term Lamer comes to mind.

The danger with that is that someone who does that might think that they solved a problem, however they might very well have not. And because of the lack of understanding they are unable to verify if the code solves the problem, nor are they able to troubleshoot the code if needed.

The software developer needs to analyze the users problems, then come up with a solution that fits the users needs. Again it’s not about the code. It’s about the solution. It requires a deep understanding of computers and the users needs and it requires analytical skills and a creative mind to come up with a fitting solution.

This is just my two cents. Please leave any comments, questions or rants below. I’d love to hear how others perceive this.