Maybe it is just me, but I think the email comes across as patronising and potentially counter-productive. Projecting superiority like this while patting developers on the head and telling them how much you respect them suggests arrogance on the part of the architect and risks alienating the team.
Also, just emailing a team about how important tests are (for instance) seems less effective than actually creating a culture in which writing code without tests is not acceptable. Whether that be through code reviews, pair programming or something else.
To set the record straight: the architect in question is a fairly accomplished guy with 19+ years of experience, and the team he was addressing has an average of 5 years.
I'm happy to say the past few months were exciting, and we completed a project estimated to complete in 5 months within 3 without too many late nights and long hours.
Actually these comments are embarrassing to me as a developer because they support the conclusion that far too many of us have the tendency to believe our own publicity. If everyone is a Randy Moss I'm beginning to wonder who is paying attention to the fundamentals and moving forward.
Ouch. I use Word as well, now that I'm an Architect. Thank you very much.
Actually, a lot of my initial work is still done in vi, and I'm always on the lookout for good software that will let me describe my diagrams in vi and automatically generate the graphics. Does anyone know a good addon to graphviz for creating flowcharts and sequence diagrams?
Many people use UMLGraph to document and reverse engineer existing Java programs. But the reason I wrote it is exactly as a tool to create UML diagrams using a textual notation. It use as a documentation and reverse-engineering tool came about, because the notation is Java-like.
Fairly obvious advice, and missing a great deal of other points, such as "Design is also King", "Don't prematurely optimise", "YAGNI", "Integration testing is as important as Unit testing", etc.
> 6. Go home and once in a while cook food. YES, real food. It will teach you the difference bet following a recipe and creating a meal
While most of the other points we've all heard many times, this one (IMHO) was actually pretty clever. This is something I've been thinking about a lot lately when I'm prepping: the parallels between cooking and writing software (since I do both a lot).
As an developer, it's interesting to look at cooking through the lens of: here's something fairly established you need to build (the dish). You have docs and RFCs (the recipe). You have tools that, while different, could be argued are more or less powerful than your IDE (knives, pans). You can complete the assignment, and get it good enough so all your tests pass (it's edible). You can refactor and tidy things up to make it a little better (seasoning).
Now how do you take it to the next step, from fine to fan-fucking-tastic? Is it the same process as engineering (reading, studying, lots of practice)? Is it just innate?
Anyway. Interesting point. Funny to see someone else is there, too.
I think the key here, though, that the author didn't mention, is that you should cook some real food for for other people. I can make food that I think is fantastic for myself, but isn't necessarily presentable.
I can slop together pasta dish full of random fresh vegetables using homemade tomato sauce. I think it's absolutely delicious, because I don't mind dumping the whole runny mess into a mixing bowl and eating out of that. Either I have to sell that strategy to my guests, or I have to put some more thought into presentation, repeatability (I have to be able to prepare the food on their schedule rather than mine) and probably, more care needs to be taken when choosing the combination of vegetables and spices.
Also, just emailing a team about how important tests are (for instance) seems less effective than actually creating a culture in which writing code without tests is not acceptable. Whether that be through code reviews, pair programming or something else.