How to teach Yourself Programming in Ten Years?
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology.
An important word here is “expertise”. You are not going to be a worldchampion in Chess after 10 years, but you can be great!
The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.
Another good thing to do might be to seek a mentor, trainer or coach that helps you stretch your current limits.
Do you know how to Remain Secure Against the NSA?
Are you a 10x engineer? developer? father? gardener?
Every week there is an article that references this ‘myth’. Go figure yourself!
There is no conclusive body of scientific research to suggest that the 10x engineer is in fact a real phenomenon, much less one that provides us with a deep and actionable understanding of the factors, conditions and stipulations of their existence. Yet we continue to regurgitate the mythology, over and over again.
Related to this a tweet from @jamesshore
I hereby define “10x programmer” as “10x more productive than *average*”. Now you define what productivity is. (Good luck with that.)
XmlSerializer - How to serialize object *with type* to string?
I need this quite often so I post it here for my future self!
public static object DeSerializeFromString(string xml, Type type)
XmlSerializer serializer = new XmlSerializer(type);
using (StringReader reader = new StringReader(xml))
public static string SerializeToString(object obj)
XmlSerializer serializer = new XmlSerializer(obj.GetType());
using (StringWriter writer = new StringWriter())
How big is your most successful team?
Microsoft tooling missing the point about Self Organizing Scrum teams
Ken Schwaber posted an interesting blog post about Microsoft and Scrum.
I’ve often wondered why Microsoft is building tooling around Scrum and doesn’t have either of the authors of Scrum, Jeff or myself, as an adviser. We could help it avoid these mistakes and keep its tools consistent with Scrum. The right process produces the right result (from Lean). Similarly, the right implementation of the right process produces the right result.
Only build tools for things in which you have expertise, not just the experience.
The biggest problem I see with the TFS Process Templates is:
People adopting it without thinking about the Template itself.
"It is from Microsoft, so it must be great!".
BTW Chris R. Chapman has a nice post related to this topic: “Missing Several Points about Scrum in VSTS v.Next”
What is a bug for you? How do you prioritize them? The bug myth!
Continuous Improvement with Cycle Time
The birth of the “classical” Project Manager
Overheard from Ken Schwaber, adapted version
If we had software projects where 1 person could do everything. And that 1 person has all the necessary skills.
—> That would be great!!!
Most of us do projects or initiatives that require more people. And those people are all individuals.
If the individuals are not working together as a team, that implies they need someone telling them:
- what to do
- plan their work
- organize their work
- organizing how they are spending their time
At that time, the team is constrained to doing no better than the person’s thought process —> This is a bottleneck
The Team is literally an enabling skill, ability for our profession.
Lets focus on building great teams!
Do you use time in your relative size estimates?
Great blog post, that shows the value of relative sizing.
Probably you don’t need a unit at all. Use T-Shirt sizes or gummi bears, but make it as abstract as possible.
The whole point of using relative sizing instead of time-based estimation is that humans are better at comparing the size of things than we are about making absolute judgement of size, e.g. we’re good at being right that building A is bigger than building B, but we’re not so good at being right that building A is about 200 metres high and building B is 150 metres.
"The team is the unit of success."
So next time Bob breaks the build (again), let’s have a look at why.
- Is it because he’s new to the team and no-one has told him how important a passing build is?
- Is it because the clients put him under a lot of pressure and he didn’t feel that he had time to run the tests?
- If it’s because he’s forgetful and careless, how do we mitigate for that weakness?
- For example, would encouraging Bob to pair program help?
Even if it does appear to come down to an individual issue, there are still process improvements to consider.
- Are we hiring slowly enough?
- Are we checking properly for a culture fit?
- Are we involving the team enough in pre-hire decisions?
Do your architects write code? Do your designers??
At Facebook, designers write code
I see companies where architects don’t write code, designers writing code?
They lack content and context. You need to use real content and page designs to understand how the design will work.
They can kickstart you off, but get real ASAP.
The more time you spend in Photoshop, the less time you are seeing interactions work.
Software is impermanent -always evolving. More than ever, our work is never over.
via “Design Lessons from 350 Million”
when my boss forces me to present a buggy application to the client
/* by freshbluelite */
McKinsey proposes to measure development team productivity with Use Cases and Use Case points and Martin Fowler’s thoughts