Some fellow posted on proggit
"Currently the top rated link on proggit is
"What did I do wrong? (or, how are you supposed to hire a programmer?)"
And the first rated comment is
What did I do wrong?
In the end, we went with the Indian company
Is this some kind of a clever troll?
As an Indian (and a partner at an Indian software consulting company), am I not supposed to be offended by this? Would your answer had been same had the company been an Israeli one? I see similar highly voted comments on proggit all the time, and its very infuriating, as obv. I generally like hanging out here."
and titled it "Dear Proggit: why the hatred for India?"
My answer
"(I am an Indian programmer living in India) You are just being too sensitive. Except for some xenophobic rednecks, no one hates India. There are plenty of unskilled Indian "developers" especially in the enterprise sw outsourcing companies who can't code to save their lives and it is only natural that people who have been burned once are leery about outsourcing work to Indian companies.
The way to fix this is to do good work, more specifically write great code. The Japanese did exactly this in manufacturing, turning around their reputation form a producer of cheap low quality gee gwas to master sof mnufacturing. Whining is useless.
Just do good work. Then do better. Rinse. repeat. The reputation and "hate" will take care of themselves.
"
I am so tired of Indian developers being ultra "sensitive" and doing everything but write good code.
An even shorter version of my answer is "Shut up and Code."
full thread
Sunday, March 21, 2010
Tuesday, February 23, 2010
No getting away from me
An email (lightly edited) I got from a friend working on Financial Software in London
"Here I am minding my own business, doing my job testing/developing Trading strategies designed by one of the Quants + Traders and what do I hear -
someone in the corner is talking about something very
mathematical - it all sounds gobbledegook to me and then I hear the word "Re-inforcement Learning" (I know you work on something like that)
I walk over, say hi (to some French mathematicians from Ecole Poly) and casually inquire what they are talking about, comes the reply - Modern Statistical Learning for predicting market behavior and tuning algorithmic trade strategies,
On the Screen - Java code - author @Ravi Mohan
There is no running away from you is there :-)
"
No there isn't!
;-)
"Here I am minding my own business, doing my job testing/developing Trading strategies designed by one of the Quants + Traders and what do I hear -
someone in the corner is talking about something very
mathematical - it all sounds gobbledegook to me and then I hear the word "Re-inforcement Learning" (I know you work on something like that)
I walk over, say hi (to some French mathematicians from Ecole Poly) and casually inquire what they are talking about, comes the reply - Modern Statistical Learning for predicting market behavior and tuning algorithmic trade strategies,
On the Screen - Java code - author @Ravi Mohan
There is no running away from you is there :-)
"
No there isn't!
;-)
Thursday, February 18, 2010
A Haskell Journey
Over the last couple of years, I've been using Haskell (oddly enough) as a scripting/shell language, somewhat akin to bash, to tie together various bits and pieces of code written in other languages. (See http://www.cse.unsw.edu.au/~dons/data/Basics.html for some shell like utilities).
One of my goals for this year is to really master Haskell so I can use it as a primary language. As I dig in, I find there are two levels of Haskell.
Level 1 consists of algebraic data types, pure (and lazy) functions, typeclasses and modules. Someone fluent in another language can (relatively) easily wrap their heads around this portion of the language and start programming. There are plenty of tutorials and books (including "Real World Haskell") that teach this style of Haskell usage.
But, sooner or later one comes across code that is written in "level 2" Haskell - making heavy use of Monads, Monoids, Arrows and all the other Category Theory goodness. Monads get an abnormal mindshare among would-be Haskell developers but there is more to Haskell than Monads. No one has really written a comprehensive guide to this bit of Haskell. The nearest we have is the TypeClassopedia (warning, PDF) but that is more a collection of links for further reading than a detailed exposition. The Wikibook is uneven. RWH does a hop-skip-and jump over these bits - a correct decision given the focus and size of the book.
What we really need is an "Advanced Haskell" book which assumes a knowledge of Level 1 Haskell and then lays out the CT bits in an orderly fashion. Monads for example, are best understood from a Category Theory perspective than through some tortured analogy to Space Stations or Elephants or whatever. Some exposition of Type Theory would help too - a knowledge of kinds, for example is very useful to decode some of the advanced bits ( TAPL's last chapters have a good exposition iirc).
In the absence of an "Advanced Haskell" book, the best option is to read the various papers, trawl the mailing lists and so on for answers to specific questions. I've learned some Category Theory before (and am fairly comfortable with Type Theory) so I haven't found this to be particularly hard but I can see how it could be (very) hard for someone without this background. Mastery of this level would be when I can code *fluently* with Comonads and such. I am not there yet.
That said, Haskell is the most elegant language I've ever used and I plan to write a lot of code in it. I plan to open source some Haskell code over the next couple of months, so we'll see how much I've really understood!
One of my goals for this year is to really master Haskell so I can use it as a primary language. As I dig in, I find there are two levels of Haskell.
Level 1 consists of algebraic data types, pure (and lazy) functions, typeclasses and modules. Someone fluent in another language can (relatively) easily wrap their heads around this portion of the language and start programming. There are plenty of tutorials and books (including "Real World Haskell") that teach this style of Haskell usage.
But, sooner or later one comes across code that is written in "level 2" Haskell - making heavy use of Monads, Monoids, Arrows and all the other Category Theory goodness. Monads get an abnormal mindshare among would-be Haskell developers but there is more to Haskell than Monads. No one has really written a comprehensive guide to this bit of Haskell. The nearest we have is the TypeClassopedia (warning, PDF) but that is more a collection of links for further reading than a detailed exposition. The Wikibook is uneven. RWH does a hop-skip-and jump over these bits - a correct decision given the focus and size of the book.
What we really need is an "Advanced Haskell" book which assumes a knowledge of Level 1 Haskell and then lays out the CT bits in an orderly fashion. Monads for example, are best understood from a Category Theory perspective than through some tortured analogy to Space Stations or Elephants or whatever. Some exposition of Type Theory would help too - a knowledge of kinds, for example is very useful to decode some of the advanced bits ( TAPL's last chapters have a good exposition iirc).
In the absence of an "Advanced Haskell" book, the best option is to read the various papers, trawl the mailing lists and so on for answers to specific questions. I've learned some Category Theory before (and am fairly comfortable with Type Theory) so I haven't found this to be particularly hard but I can see how it could be (very) hard for someone without this background. Mastery of this level would be when I can code *fluently* with Comonads and such. I am not there yet.
That said, Haskell is the most elegant language I've ever used and I plan to write a lot of code in it. I plan to open source some Haskell code over the next couple of months, so we'll see how much I've really understood!
Friday, January 15, 2010
Learning about Machine Learning
Bradford Cross has posted an awesome blog post (edit: removed link, since Bradford took down the post) titled "Learning about Statistical Learning". If you plan to work in ML, read the post, buy some of the books and work through them.
Could save you years of work if you are systematic from the beginning (I wasn't), especially if you are self taught (I am).
I work on different domains (Robotics/Computer Vision/Simulation) from Bradford and so have a different list of books. Please read Bradford's lists first. This is a supplement to his awesome post rather than a replacement.
I assume you are a good developer and you have a solid grip on algorithm analysis etc.(though, that said, see reccomendations for Discrete Math books below)
The first step..
Learn proof techniques *first*. You'll make no serious progress till you do. The best book is
Velleman's "How to Prove It" - reccomended by Bradford but I am repeating it here because this is critical.
Mathematics
In my experience you need to be somewhat comfortable with 6 branches of Mathematics before you can tackle ML. Imo, best to take a year and get these right before venturing into ML proper. (I know, it sounds awfully boring. I wasted a lot of time trying to shorten this step. In this case, the long way is the real shortcut)
(1) Calculus - best "lite" book - Calculus by Strang (free download) ,
best "heavy" books - Calculus by Spivak, Principles of Mathematical Analysis a.k.a "Baby Rudin"
(2) Some book on Discrete Math (don't know what to recommend here - I don't like Rosen's book) + a good book on say Introduction to Algorithms by Cormen et al will do [*]
(3) Linear Algebra (First work through Strang's book, then Axler's)
(4) Probability (Bertsekas is a good book for those with no prior exp) and
(5) Statistics (I would recommend Devore and Peck for the total beginner but it is a damn expensive book. So hit a library or get a bootlegged copy to see if it suits you before buying a copy, see brad's list for advanced stuff.)
(6) Information Theory (MacKay's book is freely available online)
Basic AI.
Brad suggests Mitchell's book.
I think AIMA (3d Edition) is much better. ( I am biased. I wrote and maintained the Java code for a long while -- children, don't do this. Java is an terrible language to develop AI algorithms in. If you need the JVM use Scala or Clojure -- and I think it covers a lot more than Mitchell does. Take a look at both. Pick one).
Machine Learning.
NB: you need all the linear algebra, calculus etc worked through before you hit this point
In order,
"Pattern Recognition and Machine Learning" by Christopher Bishop,
*then* "Elements of Statistical Learning" (free download).
Neural Networks:
In order,
Neural Network Design Hagan Demuth and Beale,
Neural Networks, A Comprehensive Foundation (2nd edition) - By Haykin (there is a newer edition out but I don't know anything about that, this is the one I used)
and Neural Networks for Pattern Recognition ( Bishop).
At this point you are in good shape to read any papers in NN. My reccomendations - anything by Yann LeCun and Geoffrey Hinton. Both do amazing research.
Reinforcement Learning (again this is just stuff *I* happened to specialize in for various projects, so feel free to ignore)
Reinforcement Learning - An Introduction by Barto and Sutton (follow up with "Recent Advances In reinforcement Learning" (PDF) which is an old paper but a GREAT introduction to *Hierarchical* Reinforcement learning
Neuro Dynamic Programming by Bertsekas
Computer Vision
Introductory Techniques for 3-D Computer Vision, by Emanuele Trucco and Alessandro Verri.
An Invitation to 3-D Vision by Y. Ma, S. Soatto, J. Kosecka, S.S. Sastry. (warning TOUGH!!)
Robotics.
I know only about the software/algorithms side of Robotics and that too only Probabilistic Robotics. I don't know anything about hardware, electronics or Physics.
Probabilistic Graphical Models: Principles and Techniques (Adaptive Computation and Machine Learning) (strictly speaking not a robotics book, but a lot of the theory in this book is behind the algorithms in the next book
Probabilistic Robotics (Intelligent Robotics and Autonomous Agents) by Thrun, Burgard and Fox (trivia Thrun also wrote the Robotics chapter in AIMA - did I tell you AIMA rocks as a first introduction to AI?)
And that's all folks. Happy hacking!
[*] working though Cormen et al is a humungous task and can easily consume a year or more of work. Something like Sally Goldman's new Algorithm book maybe more suited to programmers.
PS: I have been getting a lot of email asking *how* one should learn X or Y. I have no idea really. The above is a list of books that worked for me and is provided only in the spirit of "these are good books that worked for me I don't know if they'll work for you."
As to how I learned, I just read books and papers, try to understand, (a lot of banging head against wall at this point) and try to solve problems and code stuff. Beyond that I have no advice on how to learn effectively etc. I am entirely self taught and have no idea how to teach this stuff. You probably need to talk to a good prof.
Could save you years of work if you are systematic from the beginning (I wasn't), especially if you are self taught (I am).
I work on different domains (Robotics/Computer Vision/Simulation) from Bradford and so have a different list of books. Please read Bradford's lists first. This is a supplement to his awesome post rather than a replacement.
I assume you are a good developer and you have a solid grip on algorithm analysis etc.(though, that said, see reccomendations for Discrete Math books below)
The first step..
Learn proof techniques *first*. You'll make no serious progress till you do. The best book is
Velleman's "How to Prove It" - reccomended by Bradford but I am repeating it here because this is critical.
Mathematics
In my experience you need to be somewhat comfortable with 6 branches of Mathematics before you can tackle ML. Imo, best to take a year and get these right before venturing into ML proper. (I know, it sounds awfully boring. I wasted a lot of time trying to shorten this step. In this case, the long way is the real shortcut)
(1) Calculus - best "lite" book - Calculus by Strang (free download) ,
best "heavy" books - Calculus by Spivak, Principles of Mathematical Analysis a.k.a "Baby Rudin"
(2) Some book on Discrete Math (don't know what to recommend here - I don't like Rosen's book) + a good book on say Introduction to Algorithms by Cormen et al will do [*]
(3) Linear Algebra (First work through Strang's book, then Axler's)
(4) Probability (Bertsekas is a good book for those with no prior exp) and
(5) Statistics (I would recommend Devore and Peck for the total beginner but it is a damn expensive book. So hit a library or get a bootlegged copy to see if it suits you before buying a copy, see brad's list for advanced stuff.)
(6) Information Theory (MacKay's book is freely available online)
Basic AI.
Brad suggests Mitchell's book.
I think AIMA (3d Edition) is much better. ( I am biased. I wrote and maintained the Java code for a long while -- children, don't do this. Java is an terrible language to develop AI algorithms in. If you need the JVM use Scala or Clojure -- and I think it covers a lot more than Mitchell does. Take a look at both. Pick one).
Machine Learning.
NB: you need all the linear algebra, calculus etc worked through before you hit this point
In order,
"Pattern Recognition and Machine Learning" by Christopher Bishop,
*then* "Elements of Statistical Learning" (free download).
Neural Networks:
In order,
Neural Network Design Hagan Demuth and Beale,
Neural Networks, A Comprehensive Foundation (2nd edition) - By Haykin (there is a newer edition out but I don't know anything about that, this is the one I used)
and Neural Networks for Pattern Recognition ( Bishop).
At this point you are in good shape to read any papers in NN. My reccomendations - anything by Yann LeCun and Geoffrey Hinton. Both do amazing research.
Reinforcement Learning (again this is just stuff *I* happened to specialize in for various projects, so feel free to ignore)
Reinforcement Learning - An Introduction by Barto and Sutton (follow up with "Recent Advances In reinforcement Learning" (PDF) which is an old paper but a GREAT introduction to *Hierarchical* Reinforcement learning
Neuro Dynamic Programming by Bertsekas
Computer Vision
Introductory Techniques for 3-D Computer Vision, by Emanuele Trucco and Alessandro Verri.
An Invitation to 3-D Vision by Y. Ma, S. Soatto, J. Kosecka, S.S. Sastry. (warning TOUGH!!)
Robotics.
I know only about the software/algorithms side of Robotics and that too only Probabilistic Robotics. I don't know anything about hardware, electronics or Physics.
Probabilistic Graphical Models: Principles and Techniques (Adaptive Computation and Machine Learning) (strictly speaking not a robotics book, but a lot of the theory in this book is behind the algorithms in the next book
Probabilistic Robotics (Intelligent Robotics and Autonomous Agents) by Thrun, Burgard and Fox (trivia Thrun also wrote the Robotics chapter in AIMA - did I tell you AIMA rocks as a first introduction to AI?)
And that's all folks. Happy hacking!
[*] working though Cormen et al is a humungous task and can easily consume a year or more of work. Something like Sally Goldman's new Algorithm book maybe more suited to programmers.
PS: I have been getting a lot of email asking *how* one should learn X or Y. I have no idea really. The above is a list of books that worked for me and is provided only in the spirit of "these are good books that worked for me I don't know if they'll work for you."
As to how I learned, I just read books and papers, try to understand, (a lot of banging head against wall at this point) and try to solve problems and code stuff. Beyond that I have no advice on how to learn effectively etc. I am entirely self taught and have no idea how to teach this stuff. You probably need to talk to a good prof.
Monday, October 19, 2009
Looking for an apartment in Bangalore! Help!
I am looking to rent a 2 BHK (2 bedroom, 2 bathroom hall kitchen) apartment (not an independent house) in Bangalore, 1200+ sq ft. I want a quiet (so no ground floor flats), well lit (surprising how many apartments in Bangalore don't have good windows) apartment (with the usual "peripherals" - power and water backup, security, gym, swimming pool etc). Oh yeah and Airtel Connectivity. Airtel is the best ISP in Bangalore but don't cover all areas equally. I can't live without the Internetz - the main reason I don't live in Trivandrum.)
If any reader of this blog is an apartment dweller and would forward me info on any "to rent" flats, I would be very grateful. Navigating the completely broken apartment rental system in Bangalore is very painful. I would rather deal directly with the owner/renter if possible and not with a middleman, though wouldn't mind paying for a really good broker. (Most are completely clueless and just waste my time).
So if you know anyone renting a nice apartment, do send an email or tweet. Thanks in advance.
PS: I am not changing my marital status (bachelor) or food habits (non vegetarian) to "qualify" for an apartment! ;-)
Update: Found an apartment that meets all my criteria (Thanks to this blog entry! Thanks Vishy! Thanks Prakash! I owe you both a beer!).
The agreement is not signed yet, but the owners seem to be very nice people so I don't anticipate much difficulty. Touch Wood.
Update 2: The rent agreement was signed today. Thanks to everyone who sent in reccomendations. Blogs are useful things after all!
If any reader of this blog is an apartment dweller and would forward me info on any "to rent" flats, I would be very grateful. Navigating the completely broken apartment rental system in Bangalore is very painful. I would rather deal directly with the owner/renter if possible and not with a middleman, though wouldn't mind paying for a really good broker. (Most are completely clueless and just waste my time).
So if you know anyone renting a nice apartment, do send an email or tweet. Thanks in advance.
PS: I am not changing my marital status (bachelor) or food habits (non vegetarian) to "qualify" for an apartment! ;-)
Update: Found an apartment that meets all my criteria (Thanks to this blog entry! Thanks Vishy! Thanks Prakash! I owe you both a beer!).
The agreement is not signed yet, but the owners seem to be very nice people so I don't anticipate much difficulty. Touch Wood.
Update 2: The rent agreement was signed today. Thanks to everyone who sent in reccomendations. Blogs are useful things after all!
Monday, September 28, 2009
Funding vs Hiring
From Hacker News,
"Candidate A is a great programmer. He is unbelievably fast, very creative, has a lot of knowledge. He sees a problem and has brilliant solutions at hand very quickly. He just gets it. But he is not a team player. He'll go off and do stuff his way without telling anyone. Nobody sees his code before he's done. He hates discussions. He might just ignore any decisions that were made. And you never know if he'll quit tomorrow.
Candidate B is not the most creative type. His code is acceptable but you can see his limited experience. He is still good and he certainly gets the job done but there's not much you can learn from him. But he's extremely reliable and very loyal. He's happy with any work that comes along. He's a very good team player. He will give his input but accept decisions once they're made. People enjoy working with him.
What would you do? Pass on both of them? Hire A? Hire B? Wait for somebody who is a programmer as A but as reliable as B (and risk waiting forever)?"
Paul Graham responds
"Incidentally, if you're funding rather than hiring, you generally want A. That's one reason I'd rather be an investor than a boss."
(Full Discussion here)
Paul makes a subtle point (beyond the hypothetical candidate selection).
Funders and bosses think, decide, and act differently. As do "BigCo" developers vs startup founders.
Bosses want to control (or "boss around" ) their subordinates. Funders want to maximize chances of success. These are not necessarily identical, or even congruent forces.
I was thinking of a "startup within BigCo" effort I was (briefly) part of and one of the fundamental mistakes made was that no one really acted like a founder or (more importantly) a funder.
Talented (if not particularly aggressive) people, lots of money. One Year. Lots of meetings (Oh God were there meetings! We had meetings about meetings. Meetings to report results of *other* meetings. Meetings to discuss the agenda of forthcoming meetings...).
No product. No revenue. Lots of PowerPoint.
Lots of hope.
My prediction? This effort will meander along for another year or so, produce some tiny revenue streams (eventually) and then die a quiet death. Which is a tragedy. The people involved (with a couple of exceptions) were all great and I would work with any of them again in a heartbeat. The system was self defeating.
PG nails it (again).
"Candidate A is a great programmer. He is unbelievably fast, very creative, has a lot of knowledge. He sees a problem and has brilliant solutions at hand very quickly. He just gets it. But he is not a team player. He'll go off and do stuff his way without telling anyone. Nobody sees his code before he's done. He hates discussions. He might just ignore any decisions that were made. And you never know if he'll quit tomorrow.
Candidate B is not the most creative type. His code is acceptable but you can see his limited experience. He is still good and he certainly gets the job done but there's not much you can learn from him. But he's extremely reliable and very loyal. He's happy with any work that comes along. He's a very good team player. He will give his input but accept decisions once they're made. People enjoy working with him.
What would you do? Pass on both of them? Hire A? Hire B? Wait for somebody who is a programmer as A but as reliable as B (and risk waiting forever)?"
Paul Graham responds
"Incidentally, if you're funding rather than hiring, you generally want A. That's one reason I'd rather be an investor than a boss."
(Full Discussion here)
Paul makes a subtle point (beyond the hypothetical candidate selection).
Funders and bosses think, decide, and act differently. As do "BigCo" developers vs startup founders.
Bosses want to control (or "boss around" ) their subordinates. Funders want to maximize chances of success. These are not necessarily identical, or even congruent forces.
I was thinking of a "startup within BigCo" effort I was (briefly) part of and one of the fundamental mistakes made was that no one really acted like a founder or (more importantly) a funder.
Talented (if not particularly aggressive) people, lots of money. One Year. Lots of meetings (Oh God were there meetings! We had meetings about meetings. Meetings to report results of *other* meetings. Meetings to discuss the agenda of forthcoming meetings...).
No product. No revenue. Lots of PowerPoint.
Lots of hope.
My prediction? This effort will meander along for another year or so, produce some tiny revenue streams (eventually) and then die a quiet death. Which is a tragedy. The people involved (with a couple of exceptions) were all great and I would work with any of them again in a heartbeat. The system was self defeating.
PG nails it (again).
Saturday, September 26, 2009
Let the Agile Fad Flow By
The blogosphere is ablaze with"duct tapers" vs "agilists". As usual, there isn't much logic behind all the fiery arguments.
This is what happened. Peter Seibel interviewed Jamie Zawinski about how he built the original Mozilla browser for his *great* book Coders at Work. In it, Jamie was scathing about design pattern cultists who kept waving the "Gang of Four" book around and having intense discussions about the "right" pattern and so on, but couldn't write good code to save their lives (Sounds like some people we encounter today? Read on!). Joel Spolsky, writing a review of the book took a dig at what he saw as the successors of the design patterns cultists - people who write books and attend conferences etc and wave different books around.
Robert Martin, one of the chaps who signed the Agile "Manifesto" wrote a very logic lite, but moderate(for him), article juxtaposing "Duct Tape programmers" against what he calls "Clean Code" programmers. A few more bloggers took their lead from him and blew this artificial dichotomy between "shipping" coders and "clean coders" into a full fledged blog war about (as usual) nothing much.
The first thing to note is that this is a storm in a teacup. For all the fury on blogs and twitter, essentially people who really write great code and ship continue to do that, not paying any attention to these passing fads.
Software has, from the time it became important enough to build businesses round, always had flaky methodologies and people who try to sell them.
Just in my experience, first there were the "OO will save the world" hypesters, including the design patterns evangelists - this was the crowd Jamie encountered. Then there was RUP, then XP, then agile, now "lean software".
The common pattern in all these fads (and a quick way to recognize these things as fads) is to realize that the set of people who try to sell methodologies and the set of people who are brilliant programmers, product designers and so on are completely disjoint.
Do a thought experiment. Think about some brilliant programmers you know, the "change the world with code they write" type folks. For me these are people like Peter Norvig and John Carmack and Paul Graham and Linus Torvalds. You may have other heroes.
Can you imagine these people peddling agile? Just try envisioning it. Linus Torvalds trying to become a Scrum Master?
Your mind will melt down.
Think about people who've designed world changing products. (Jonathan Ives who designed the IPod for example) Do these people peddle methodologies or act as methodology consultants? Does Steve Jobs do this? Would Warren Buffet do this?
Here is the secret. Nobody who is really good at programming/product design/marketing/business (or anything) will demean himself by trying to make money telling other people how to do what they are good at. They'd rather do whatever it is they are best in the world at. World Champions may become coaches when they are old and tired and broken down, not when they can still play and win.
The standard defence is "but, but, but we are coaches. Even Tiger Woods has a coach, Coaches aren't necessarily the best players".
Yes in some fields coaches have value. The interesting thing is that it is Tiger Woods chooses a coach, and validates his coaches' skill by becoming the best golf player in the world, not the other way round.
When Linus Torvalds hires Uncle Bob to educate him about how to write Kernel Code better, or Tim Sweeney hires Ron Jeffries to help him design the next Unreal Engine, then then yeah they are "coaches". The fact is, sports doesn't map to software all that well in this aspect.
The best programmers don't hire "agilists" or "RUP Experts" or "Six Sigma Black belts" or whatever as coaches. If they have design issues to thrash out they talk to other brilliant developers. Brilliant product designers might talk to other brilliant product designers.
Fact of the matter is, "agile coaches"(and other methodology vendors) are hired by some combination of mediocre corporations, mediocre managers, and mediocre teams. Agile in particular rose in the enterprise world and that is where its focus (rightly) remains. So yes, if you work in the enterprise world, you sometimes get stuck with such "coaches" and get caught up in the latest methodology fads. It is just something that goes with the job. You might even want to become such a "coach" figure than muck around with some 10 year old accounting module from hell. It is an easier life. More power to you.
Now I'll tell you how to shut up an agile (or any other methodology evangelist). From my comment on Luke Halliwell's blog post, "the Agile Disease"),
"
The problem with agile is not “consultants” per se but “consultants” who have no credibility building and delivering great software.
For Games, when John Carmack or Tim Sweeney advocate agile for game studios, I’ll listen.
When its someone who has no product we can judge, advocates a methodology that failed in its very first project, where it originated (spare me the redefinitions of “failure” If the client kicked the team out that is “failure” enough for me) that is a different kettle of fish entirely.
Next time an “agile consultant” pitches for your money, ask him to show you code he has written that made a substantial change in your domain.
“I wrote/ led-the-team-that created Doom/Unreal/World of Warcraft” is acceptable.
“Oh yeah I created this uber cool enterprise system which you can’t look at and I don’t have any open source code, but I know how to write clean code and to “lead” teams, cross my heart” isn’t."
"
The key sentence is this,
"Next time an “agile consultant” pitches for your money, ask him to show you code he has written that made a substantial change in your domain."
The fact is no agile consultant today has written any world changing code,nor have they designed any world changing products (Imagine the guy who designed the IPod peddling a product design methodology for a living) or built or run any world changing companies.
The "coach" argument is dismissed easily too. If they are coaches, are their clients brilliant programmers? (this is where the Tiger Woods analogy falls down) It is always some El Crapola enterprise project *manager* who hires a methodology coach, never a great programmer, or team of great programmers (Do you think when Paul Graham, Robert T Morris and Trevor Blackwell were working on ViaWeb, they needed an "agile coach"?) .
Coming back to the Jwz-Spolsky-Uncle Bob tangle, just think of who among these three is trying to sell you something. Jamie doesn't sell anything (well I think he sells drinks and entertainment at his club/bar/whatever but he doesn't sell anything programming related). Spolsky sells a Bug Database. Uncle Bob sells Training Courses (via his company Object Mentor).
Now there is nothing wrong with selling anything in a capitalist world. But there is a motto every buyer should live by, Caveat Emptor- Buyer Beware. It is upto you to be on the defense against snake oil salesmen (of whatever category) and it is up to you to ensure you don't spend money on being "coached" to become a good developer by people who aren't themselves great developers.
TDD vs Duct Tape is a false dichotomy. There can be great design and code without TDD (or even unit tests) and rigorous TDD can result in terrible, ultra brittle codebases. (Private joke for ThoughtWorkers of a specific era - anyone seen "Class FieldedBusinessObject " recently?! Those were the days!).
TDD as a "design methodology" has no legs (See an agile "guru" struggle to write a Sudoku Solver). Having unit tests helps in regression testing and maintenance. That's it. If you need unit tests to "design" you aren't a great designer of software. Sorry. Sad but true.
Every fad eventually dissipates and sometimes they leave behind (very small) nuggets of value. The "everything should be modelled with Objects" fad passed (remember all the books from Booch and Rumbaugh and Iverson about how to do Object design?). Design Patterns are almost dead as a movement. Agile is facing a backlash (and will die soon enough).
Will there be other as yet unimagined fads (and associated methodology consultant/certification types) who'll replace agile? Of course. As long as fools with money are willing to be "coached" into improving their programming ability, there will be demand for such fraudsters and where there is demand, there will be supply. Whether you should be part of this supply/demand equation, and at what cost to your soul, you have to decide.
Let all these distractions and squabbles flow by. Focus on doing good work (however you define good work). Learn from people who are really good in your chosen field. Shut out the babbling of the methodology vendors and consultants.
So if you are a programmer trying to get better, just write the best code you know how. Then get better. Listen to people who are better programmers than you (Read "Coders At Work"!). Ignore the fads.
Update: jwz's reaction to this whole fiasco "It's such a strange article, in that it's mostly favorable to my point of view but with such a breathless amazement to it, like he's just discovered an actual unicorn or something. "Look, everybody! Here's a hacker who actually accomplished things and yet he doesn't fetishize the latest fads that I and all of my friends make our living writing about!"
As Luke Gorrie tweeted, "The takeaway from jwz C@W interview isn't "write crappy code,"but "quit your stupid enterprise job & have an impact on the world""
Amen!
[1] What makes the book "Coders At Work" awesome and a book every programmer should read, in my opinion, is that the author interviews great programmers, not random fad vendors. There is a lot of wisdom in the book.
If he ever writes "Methodology Vendors at Work" how many people will buy a copy? ;-)
This is what happened. Peter Seibel interviewed Jamie Zawinski about how he built the original Mozilla browser for his *great* book Coders at Work. In it, Jamie was scathing about design pattern cultists who kept waving the "Gang of Four" book around and having intense discussions about the "right" pattern and so on, but couldn't write good code to save their lives (Sounds like some people we encounter today? Read on!). Joel Spolsky, writing a review of the book took a dig at what he saw as the successors of the design patterns cultists - people who write books and attend conferences etc and wave different books around.
Robert Martin, one of the chaps who signed the Agile "Manifesto" wrote a very logic lite, but moderate(for him), article juxtaposing "Duct Tape programmers" against what he calls "Clean Code" programmers. A few more bloggers took their lead from him and blew this artificial dichotomy between "shipping" coders and "clean coders" into a full fledged blog war about (as usual) nothing much.
The first thing to note is that this is a storm in a teacup. For all the fury on blogs and twitter, essentially people who really write great code and ship continue to do that, not paying any attention to these passing fads.
Software has, from the time it became important enough to build businesses round, always had flaky methodologies and people who try to sell them.
Just in my experience, first there were the "OO will save the world" hypesters, including the design patterns evangelists - this was the crowd Jamie encountered. Then there was RUP, then XP, then agile, now "lean software".
The common pattern in all these fads (and a quick way to recognize these things as fads) is to realize that the set of people who try to sell methodologies and the set of people who are brilliant programmers, product designers and so on are completely disjoint.
Do a thought experiment. Think about some brilliant programmers you know, the "change the world with code they write" type folks. For me these are people like Peter Norvig and John Carmack and Paul Graham and Linus Torvalds. You may have other heroes.
Can you imagine these people peddling agile? Just try envisioning it. Linus Torvalds trying to become a Scrum Master?
Your mind will melt down.
Think about people who've designed world changing products. (Jonathan Ives who designed the IPod for example) Do these people peddle methodologies or act as methodology consultants? Does Steve Jobs do this? Would Warren Buffet do this?
Here is the secret. Nobody who is really good at programming/product design/marketing/business (or anything) will demean himself by trying to make money telling other people how to do what they are good at. They'd rather do whatever it is they are best in the world at. World Champions may become coaches when they are old and tired and broken down, not when they can still play and win.
The standard defence is "but, but, but we are coaches. Even Tiger Woods has a coach, Coaches aren't necessarily the best players".
Yes in some fields coaches have value. The interesting thing is that it is Tiger Woods chooses a coach, and validates his coaches' skill by becoming the best golf player in the world, not the other way round.
When Linus Torvalds hires Uncle Bob to educate him about how to write Kernel Code better, or Tim Sweeney hires Ron Jeffries to help him design the next Unreal Engine, then then yeah they are "coaches". The fact is, sports doesn't map to software all that well in this aspect.
The best programmers don't hire "agilists" or "RUP Experts" or "Six Sigma Black belts" or whatever as coaches. If they have design issues to thrash out they talk to other brilliant developers. Brilliant product designers might talk to other brilliant product designers.
Fact of the matter is, "agile coaches"(and other methodology vendors) are hired by some combination of mediocre corporations, mediocre managers, and mediocre teams. Agile in particular rose in the enterprise world and that is where its focus (rightly) remains. So yes, if you work in the enterprise world, you sometimes get stuck with such "coaches" and get caught up in the latest methodology fads. It is just something that goes with the job. You might even want to become such a "coach" figure than muck around with some 10 year old accounting module from hell. It is an easier life. More power to you.
Now I'll tell you how to shut up an agile (or any other methodology evangelist). From my comment on Luke Halliwell's blog post, "the Agile Disease"),
"
The problem with agile is not “consultants” per se but “consultants” who have no credibility building and delivering great software.
For Games, when John Carmack or Tim Sweeney advocate agile for game studios, I’ll listen.
When its someone who has no product we can judge, advocates a methodology that failed in its very first project, where it originated (spare me the redefinitions of “failure” If the client kicked the team out that is “failure” enough for me) that is a different kettle of fish entirely.
Next time an “agile consultant” pitches for your money, ask him to show you code he has written that made a substantial change in your domain.
“I wrote/ led-the-team-that created Doom/Unreal/World of Warcraft” is acceptable.
“Oh yeah I created this uber cool enterprise system which you can’t look at and I don’t have any open source code, but I know how to write clean code and to “lead” teams, cross my heart” isn’t."
"
The key sentence is this,
"Next time an “agile consultant” pitches for your money, ask him to show you code he has written that made a substantial change in your domain."
The fact is no agile consultant today has written any world changing code,nor have they designed any world changing products (Imagine the guy who designed the IPod peddling a product design methodology for a living) or built or run any world changing companies.
The "coach" argument is dismissed easily too. If they are coaches, are their clients brilliant programmers? (this is where the Tiger Woods analogy falls down) It is always some El Crapola enterprise project *manager* who hires a methodology coach, never a great programmer, or team of great programmers (Do you think when Paul Graham, Robert T Morris and Trevor Blackwell were working on ViaWeb, they needed an "agile coach"?) .
Coming back to the Jwz-Spolsky-Uncle Bob tangle, just think of who among these three is trying to sell you something. Jamie doesn't sell anything (well I think he sells drinks and entertainment at his club/bar/whatever but he doesn't sell anything programming related). Spolsky sells a Bug Database. Uncle Bob sells Training Courses (via his company Object Mentor).
Now there is nothing wrong with selling anything in a capitalist world. But there is a motto every buyer should live by, Caveat Emptor- Buyer Beware. It is upto you to be on the defense against snake oil salesmen (of whatever category) and it is up to you to ensure you don't spend money on being "coached" to become a good developer by people who aren't themselves great developers.
TDD vs Duct Tape is a false dichotomy. There can be great design and code without TDD (or even unit tests) and rigorous TDD can result in terrible, ultra brittle codebases. (Private joke for ThoughtWorkers of a specific era - anyone seen "Class FieldedBusinessObject " recently?! Those were the days!).
TDD as a "design methodology" has no legs (See an agile "guru" struggle to write a Sudoku Solver). Having unit tests helps in regression testing and maintenance. That's it. If you need unit tests to "design" you aren't a great designer of software. Sorry. Sad but true.
Every fad eventually dissipates and sometimes they leave behind (very small) nuggets of value. The "everything should be modelled with Objects" fad passed (remember all the books from Booch and Rumbaugh and Iverson about how to do Object design?). Design Patterns are almost dead as a movement. Agile is facing a backlash (and will die soon enough).
Will there be other as yet unimagined fads (and associated methodology consultant/certification types) who'll replace agile? Of course. As long as fools with money are willing to be "coached" into improving their programming ability, there will be demand for such fraudsters and where there is demand, there will be supply. Whether you should be part of this supply/demand equation, and at what cost to your soul, you have to decide.
Let all these distractions and squabbles flow by. Focus on doing good work (however you define good work). Learn from people who are really good in your chosen field. Shut out the babbling of the methodology vendors and consultants.
So if you are a programmer trying to get better, just write the best code you know how. Then get better. Listen to people who are better programmers than you (Read "Coders At Work"!). Ignore the fads.
Update: jwz's reaction to this whole fiasco "It's such a strange article, in that it's mostly favorable to my point of view but with such a breathless amazement to it, like he's just discovered an actual unicorn or something. "Look, everybody! Here's a hacker who actually accomplished things and yet he doesn't fetishize the latest fads that I and all of my friends make our living writing about!"
As Luke Gorrie tweeted, "The takeaway from jwz C@W interview isn't "write crappy code,"but "quit your stupid enterprise job & have an impact on the world""
Amen!
[1] What makes the book "Coders At Work" awesome and a book every programmer should read, in my opinion, is that the author interviews great programmers, not random fad vendors. There is a lot of wisdom in the book.
If he ever writes "Methodology Vendors at Work" how many people will buy a copy? ;-)
Subscribe to:
Posts (Atom)