There are many traits a good developer has. Focus. Sense of Quality. Interest in what he does. Knowledge of programming languages and skills in software development. An opinion. Team player. Update see comments: Being creative and innovative. Propose ideas.
But the things I most value are professionalism and getting things done.
Those are similar to the one Fog Creek and Joel Spolsky find important. Joel on Software values:
First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done.
Why professionalism? There is not enough sense of a profession on our industry. We do need more professionalism to be taken serious by others. By our customers. Noone would argue with an account about his practices, or with a surgeon about his. The only high-profile person caring about professionalism seems to be Uncle Bob. This can be felt in many of his arguments:
Look, TDD is not my religion, it is one of my disciplines. It’s like dual entry bookkeeping for accountants, or sterile procedure for surgeons. Professionals adopt such disciplines because they understand the theory behind them, and have directly experienced the benefits of using them.
Professionalism is about not doing things that are stupid. Not cutting corners. Have pride in your work and write clean code. Get the software development industry and your job to a level where surgeons and accountants have been for centuries.
Why gettings things done? In the end, what counts is money earned. Everything else is a proxy. If you want to get paid, your company needs to earn money. Honour deadlines. Getting things done means no gold plating. It means understanding the necessity for business to get features to their customers. Suppressing the urge to develop a framework out of everything, to develop frameworks first before you really know what is needed. Write frameworks when it helps you getting things done. To dive into large refactorings at the wrong time.
You need to strike a balance between both. Too much professionalism and your customers will be annoyed. As will be your boss and your colleagues. It means you will make professionalism and end in itself and forget about getting things done. Too big a focus on getting things done will make you cut corners. Write bad code. Being not professional.
Your company needs to support you with both – a environment for professionalism and letting you getting things done. Many companies don’t. Some focus too much on professionalism, some focus too much on getting things done. What if your environment doesn’t support you? Joel writes in another article about you getting things done:
A lot can be done to improve the project just by one person doing it. Don’t have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests?
And most managers will value you highly when you get things done.
What about you, what do you value? I’d like to hear in the comments.
There is the well established notion of what Scrum-But is. There is also a clear definition of Scrum – although people still argue if someone is doing Scrum or his process is only Scrumish. But more or less, territory is known. At least in the two dimensions, black and white about Scrum or not-Scrum.
After many years of Scrum people have inspected and adapted for many iterations. Additionally the current increase in lean and Kanban adoption engulfs many Scrum projects. Developers are using Scrum together with XP and some believe you are more successfully and productive when using XP practices together with Scrum.
There is no term describing these efforts. People who have moved beyond Scrum-by-the-book, adapted lean values, moved to flow and continuous deployments and who have perhaps dropped some of their Scrum practices (LINK mein blog) like iteration reviews, what should they call their process? Strong Scrum enthusiasts would say don’t call it Scrum at all. Call your process agile or lean. But with iterations, a ScrumMaster, ProductOwner and story point estimation, this sounds too weak and doesn’t reflect the still strong Scrum base of the practice.
I suggest calling these processes Trans-Scrum. This term is for people who still believe in Scrum and have adopted Scrum successfully, not those who dropped the effort for whatever reason (and this is fine!). As long as Scrum and the values of Scrum are the base of your process, you’re Trans-Scrum.
This would help communication between people, talking about processes and sharing knowledge and wisdom. I often struggle expressing myself what we do here. This is difficult because when you, as a Trans-Scrumer, tell people you do Scrum they get the wrong impression. If you tell them you don’t do Scrum, they also get the wrong impression. Even more if you tell them – who would? – you do Scrum-But? [1]
Only when you move beyond that, what some surely will as they adapt even more to their context, start calling your process something else.
What would you call this process? Scrum 2.0? Scrum++?
[1] The difference between Scrum-But and Trans-Scrum is, in the Toyota sense, that you’ve done practices in Trans-Scrum and after learning you’ve dropped them as not necessary. While with Scrum-But you don’t do these practices from the start because you think they don’t work for you.
Recently I’ve read a blog post by Keith Dahlby. It was titled “Is Functional Abstraction Too Clever?”. The title sounded more rhetoric because clearly Keith was very satisfied with the code he presented.
But it got me thinking again. After some time with Lisp at university, some Haskell and some functional thinking in Ruby, I’m deep into Scala for some months. I’ve written some functional code before in Java, but I’m using much more with Scala now. Many examples are mostly thinking and syntactic sugar to me, not something I can put a finger on: this is functional.
Haskell examples clearly are more functional – how so? – and some blog authors give very nice functional solutions. Some blog posts by Raganwald and Debasish gave me great insights into functional composability. But many examples of people new to functional programming do not look functional to me.
Keith says about functional programming:
To me, this is the value proposition of functional programming. By expressing the algorithm in terms of common operations, we’re able to spend more time thinking about the problem than the details of the solution.
Let’s take a look at his code:
static int[] GetSlots(int slots, int max)
{
return new Random().Values(1, max)
.Take(slots - 1)
.Append(0, max)
.OrderBy(i => i)
.Pairwise((x, y) => y - x)
.ToArray();
}
Looks more like a filter pipeline than functional programming. Especially compared for example to the things Apocalisp does with functional programming. Years ago I wrote a rendering pipeline, before the functional hype, and it was just a collection of Filter objects which filtered and transformed input into output. There were many users, and no-one thought of it as “functional”. Keith goes on:
A similar change in an imperative implementation would almost certainly have been more involved and prone to error.
The example is written in C# so it supports closures neatly, transformed to Java it might look like this (the generics are not totally correct, I’m spoiled by Scala):
static int[] getSlots(int slots, int max) {
return new Random()
.values(1,max)
.take(slots - 1)
.append(0, max)
.orderBy(new Order[int]() { public int by(int i) { return i })
.pairwise(new Folder[int]() { public int fold(int x, int y) { return y - x })
.toArray();
}
More involved? More prone to error? Not so sure. Someone with an OO background would righteously say: Sure this is OO. Method chaining and objects.
As we all know, Java is not a functional programming language, but an object oriented one. There isn’t much difference here, some shorter code, some syntactic sugar for creating functions. The only difference between object oriented and functional being that OO is more noisy? Is OO as superset of FP? The line blurs even more with Functional Java. Is functional not only a way of thinking? Immutable, side effect free, composable code blocks?
Is this example functional? What is functional? Your view would be appreciated, especially if you’re one of the usual suspects.
