29. May 2013 22:59
A little while ago I wrote a post the fallacies of the tech recruitment process. While it is nice to point out what is wrong, I never actually provided the proper way to find out if a senior developer might be experienced enough and the right fit for your company, so this time I decided to put my money where my mouth is, and tell you how to hire a senior developer.
Why hire a "senior developer" and what is a senior developer exactly
In my opinion, a senior developer is a developer who manages to think out of the box, and who does not stop reasoning about finding a solution at technical boundaries. A senior developer is somebody who tries to provide business value for every single step he makes, while a junior is more or less focussed on implementing the whole thing, a senior thinks about what he has to do and why he has to do it...
A senior can be tens to hundreds of times more productive business-value wise then a junior.More...
1. December 2012 06:10
As one does typically develop features in parallel, and some features can not be released while others can, a lot of software teams seem to have problems with their source control.
In this post I will describe Simplified Feature Branching usable with git or any other DVCS.
This model is not rocket science, and is a further simplification of Adam Dymitruk's post on feature branching.
It assumes you use proper release cycles and versioning during the software development lifecycle.
Whenever I mention "feature" in this post, I actually mean "feature" or "bugfix", but I am a lazy b*d.
The main idea: simplification
Make everything as simple as possible, but not simpler - Albert Einstein
Whenever things start to get complicated, we should attempt to simplify them by breaking it up into smaller parts. This is exactly what Simplified Feature Branching does. We make the distinction between branching and integration.
17. November 2012 00:08
During one of my more recent interviews I got an assesment from two different persons. While I still have no idea about the definitive outcome, the different types of questions they both asked triggered me to think about what kind of personality type they would be, so I started wondering how personality types are related to development....
First things first: MBTI
Before we can determine the effect of your personality on your development, we will start by defining MBTI, so let us begin with the wikipedia definition:
The Myers-Briggs Type Indicator (MBTI) assessment is a psychometric questionnaire designed to measure psychological preferences in how people perceive the world and make decisions.
They do this by categorizing your personality in four dimensions; your gradation in every dimension is not a boolean, but rather a range (i.e. -1 to +1).
I will describe each of the four dimensions in detail, and explain how they impact your development:
#1 Attitude: "Extraversion" versus "Intraversion" (E vs I)
Attitude is about the way evolve an idea and get inspired: some get inspired by doing and experimenting, while others get inspired by thinking about things.
- Development by people with high "Extraversion" is driven by
- experimenting with code
- evolving ideas in small incremental steps by talking with other people
- doing things right
- Development by people with high "Intraversion" is driven by
- an internal thought process
- thinking ideas through before talking about it with other people
- doing the right thing
On a sidenote, "extraversion" is not a typo; it is the way you spell this word in MBTI terms.
16. November 2012 08:49
Note: I would like to thank @gbarrs for reviewing my blog post almost instantly, and also the offer of @GraemeF, @MarkRendle, @swaggerdmangene and @moldyseaswimmer to be a reviewer. Without them, there would be a lot more Dunglish in this post...
Why I like my job.
I have been hooked into computers ever since I wrote my first few lines of Basic on my mothers' brand new TRS-80 Model 3 with 64Kb of ram and 2 - yes 2 !!! - diskdrives of a whopping 178Kb. (Actually, I did not write the code, but I copied it character by character from a textbook that might have looked like this, but in my defense, I was about 7 years old).
The first program probably looked like this:
10 PRINT "HI, WHAT IS YOUR NAME?"
20 INPUT N$
30 PRINT "HELLO, ",N$
Exciting, is it not? In the five years that followed, I learned almost every in and out of this machine, where to peek and poke in memory, how to set pixels on the screen (monochrome, 128x48 resolution, imagine that), which ASCII codes to send to my dot matrix printer to switch control modes, ...
When I was about twelve years old, I had written a drawing application, complete with circles, boxes, Bresenham lines, and even the possibility to print the graphics on the (very noisy) dot matrix printer (remember those printers which had to print on chained paper?).
31. October 2012 10:21
“Almost all quality improvement comes via simplification of design, manufacturing... layout, processes, and procedures.” - Tom Peters
As I was tinkering around with Erlang/OTP and some other stuff, I suddenly experienced yet another "aha-erlebnis": there is a huge difference between something that is simple and something that is easy, but a lot of people tend to miss this rather important distinction.
18. January 2012 03:38
Over at a private LinkedIn newsgroup for ENTP personality types, somebody posted a link to "The Seven Habits of Spectacularly unsuccessful Executives". This is a great article, but not a lot of help IMO, instead of telling what not to do, one might be reversing the reasoning, and try to figure out what to do.
I posted this blurb in a comment on the newsgroup, and I figured I might as well post it on the blog as well...
Here we go:
The Seven Habits of Possibly Spectacularly Successful Executives
27. December 2011 04:25
One of my main motivators, my youngest son Matisse #PrideAndJoy
I like the concept of retrospectives; it makes you self-reflect and think about the paths you followed and want to follow in the future. As it has been 2 years ago since my latest retrospective, I think doing a post on it right now might be a good idea.
18. December 2011 05:05
I am currently in the process of studying F# - a functional programming language -. Since I am a big fan of meta-cognition, I am trying to find out how the mindset of the functional programming paradigm differs from that of a C# one (i.e. the more conventional, object oriented paradigm).
This essay also tries to point out some existing bridges to the functional paradigm that are currently implemented in the imperative programming language C#.
What is "Functional programming" exactly ?
I will reference wikipedia - while it still exists - for the definitions:
In computer science, functional programming is a programming paradigm
that treats computation as the evaluation of mathematical functions
and avoids state and mutable data.
It emphasizes the application of functions, in contrast to the imperative
programming style, which emphasizes changes in state.
Let us start with the first bit:
28. November 2011 03:20
The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool, so somebody without any prior experience should be able to boot a CQRS app in a few minutes.
The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app.
The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.
Scritchy is not "the framework to write CQRS apps"; Scritchy is a framework that tries to provide you a learning platform where you can start grasping the basic principles, advantages and disadvantages in using CQRS.
Once you understand the basic principles behind the CQRS setup, and why everything is setup the way it is, I would advise anybody to gradually replace parts of the framework and just opt for whatever approach you like, using proper message busses, pub/sub/...
If you write your app following the conventions Scritchy dictates, the only thing you need to change to remove the Scritchy dependency is the base object your Aggregate Root inherits from; that is the only dependency that is ever necessary in you app implementation. This was by design,to make future migrations as easy as possible.
I wrote this framework to enable a dev new to CQRS to get his app up and running in a few minutes... But apparently that is not enough....
6. October 2011 02:38
I just finished commenting someone's opinion on the MBTI personality type in a linkedin status update.
As you might have read in my previous post regarding "The secret sauce of great leadership - IMO ;)" I am an avid fan of determining your own personality type in order to improve yourself.
Because this person had seen a presentation by Patrick Vermeren on the myth of MBTI, he retweeted the following:
I wish there was a test to take to find out how much you hate Meyers-Briggs (MBTI). I'd score off the charts.
Since I most certainly do not agree, I commented some things on the linkedin thread. As I think the comment might have some value for my blog readers as well, I decided to post it here as well: