jakubholynet

Well, in Norway nearly everybody uses "Scrum" but Scrum is not always Scrum. To make it rock, you need a certain mindset - in the team and the company - and culture. It is primarily about values and culture, not processes. Changing culture is hard. Maybe a different process might help with it (if it blends better with its current state) or may be not. The state os SW development in general makes me sad panda, especially after having read Poppendieck's Lean SW development: From Concept to Cash and then looking at real-world project all around.

I would be coding for fun :-) Working in languages and toolchains of my choice (Clojure, f.ex.), helping organizations worth helping (NGOs,...). But that would be only a part-time activity, I would use the other part for stuff I like & never have enough time for - yoga, teaching, ... .

You are right, we all do this. What is missing from this is feedback: how do I know if my design is good enough or what are its pros & cons? (Since often there is no absolute "good".) That is something I am trying to provide: showing two implementations of the same thing, discussing the advantages and disadvantages of each in relation to general coding and design principles. Thus it helps to learn not only how to do a particular task and how somebody else has solved it but also to think critically about design and the ability to relate to design principles. At least that is what I hope :)

Thank you, bjoerns! That is actually a good suggestion and modern screens are wide enough for that. I am afraid that Wordpress won't allow me to do that but will explore it.

> - Assign a career mentor > - Devise and maintain a career development plan for each prospect

These are great advices. The question is how to turn them into practice. People do not become great mentors by just becoming appointed :-(

I agree there is much more stuff than writing code.

> Teaching them the value of well organized source control and good commit notes goes a long way.

This is way too low level compared to what we are looking for. We want to find out how to help people learn quickly the basic values and principles that will enable then to proceed on the path towards learning how to build the right thing and how to build it right.

The question is not so much what to teach (there are great resources on that - Clean Code, Pragmatic Programmer, Effective Java, XP explained, ...) but how. And by how I mean little more concrete than "give them a mentor to help them" (we have tried that - but neither the mentor nor the mentee really know what to do).

> Give them real life projects that you will use.

We do that. But we feel it is not enough to help people grow quickly. We are looking for ways to make the learning process as effective as possible.

Some of the new stuff is mentioned at http://www.joyofclojure.com/2nd - - ClojureScript - more on "thinking" techniques, f.ex. unification, logic programming, constraint solving, declarative programming - Data-orientation: "dive deeply into viewing applications (and even code itself) through a data-centric lens"

We use Guice which also allows that. But that doesn't address some of the key points he makes, such as - runtime x compile time wiring - wiring is based on types so injecting differently set up instances is difficult (we have a hell of Providers and different annotations to pick the right kind of instance injected) - non-transparency of the wiring process (sice it is performed by the magical IoC container)

I agree with a lot of what he writes. At the same time I believe there are cases where I would appreciate some kind of automation for wiring (f.ex. if I want a fresh instance for each session or request). And there are certainly cases when runtime wiring - as in the mentioned case of plugins - is useful.

Sorry but to me this hears similarly too "coders do not care about why runtime speed is slow, they just want it fast". You cannot get gut runtime performance without understanding the performance constraints of data structures and algorithms you use, Similarly, when using Scala, you must be aware of the performance cost - in compilation time - of the various features and act accordingly. So yes, what can be fixed should be fixed - but I am happy with having the possibility to trade ocassionally a powerful feature that will make my coding simpler for some unavoidable compilation delay. (Though I would of course prefer the compilation to be instantanous.)

PhatnomJS and Buster really seem to be the cool kids. I hope to see more tests of front-end code integrated in Jenkins & similar ones soon.

Hi Jacques,

Thank you for your comment, I thoroughly enjoyed it. Thank you also for summarizing the many forseeable possible discussions upfront so that we could have avoided them here.

The books were chosen by a group of five, half of us with 10-15 years of experience, so no, they aren't the latest books the author by a chance happend to read.

I admit that, as others have complained, the title might be percieved as misleading. The reason is that these are books that our company recommends to its developers and we want the developers to be something more than coders (= what most people understand under 'developer'). Though it's important to write great code, it's even more important, IMHO, that it is the right code that gets written, i.e. that the resources available are used to produce the maximal business value possible (and we believe that this cannot be planned but must be discovered based on feedback from reality - that's why lean/agile). Going quickly (great coding skills) in the wrong direction isn't progress.

Some of us have read Code Complete or The Pragmatic Programmer but it hasn't made it into the list. More of us will read it now and we will reevaluate the list afterwards. I hope it's good with you :-)

Sounds interesting, good luck!

Thread switching is certainly costly and not really necessary for high-performance systems as proved by the the LMAX/Disruptor architecture.