In this article, Ted Bergeron shows you how to use the Validator component of Hibernate Annotations to build and maintain validation logic easily in your Web apps.
FullDuplex.org provides us with a funny list of things to do to “look busy”.
Hereâ€™s a few tips Iâ€™ve learned in my short time on this earth that have kept me from getting too much accomplished.
He goes on to explain his “tips”.
It left me thinking two things. First, I’m very glad he’s not on my team, second, the value of scrum and agile methodologies to get rid of the dead weight. Here’s my response to it:
I’m a lead in a web development team, and I manage and assign work for web developers. This is the behavior that gets you fired from my team.
Let’s analyze it shall we?
Look Busy/Look Stressed: We’re a Scrum team, we meet every day to talk about what we did the day before, what we will do today, and what roadblocks we have in our way. So why aren’t you asking for help? I have no use for web devs with such little people skills that they won’t even ask other members of their peer group for help. If you can’t be on a team, maybe you should go independent and not work on a team.
Speak Quickly/Hide/Break Limb/Make Excuses/Never Leave your office/rearrange furniture,etc: The only thing here that may work is breaking a limb. And even then if that happened to you it would make you a prime candidate for pairing with another developer. All the others, your non-activity would show up on the cvs commit log. In my team we have a great cvs mailer that shows colored differences of what you did, and I check it daily.
Choose a Profession people don’t understand: Your manager is probably not a techie, or he’s as lazy as you are about checking your work. You’re a perfect example why only techies can manage techies, and techie managers need to code at least 20% of their time on the current project so they can keep their skills. Also following the cvsspam list helps understand the issues.
So you see, using Scrum or other Agile methodologies underscores the lack of value of these people and will make it obvious who needs to drop off your team. Either that or they’ll shape up via peer pressure, which in the long run will make the ex-lazy team member happier as well.
As I watch my little one play with his trains (he’s still pre-videogames) I can see the essence of the scientific method playing over and over with his hands and his eyes.
Try to put the big train and attach it to the little train. It doesn’t work. How about the toy car? Nope, not that either. At the end he has all the magnetic pieces put together properly and then says "choo-choo!" as he pulls the locomotive. Now he’s trying to place a small "Jojo Circus" figure as a "passenger" on top of the train. He pulls it a couple of times but it keeps falling, until he realizes that the bendy legs fit perfectly around the oil tanker car. Then he pulls everything apart and tries it again, this time in a different configuration.
Will Wright on Wired:
Just watch a kid with a new videogame. The last thing they do is read the manual. Instead, they pick up the controller and start mashing buttons to see what happens. This isn’t a random process; it’s the essence of the scientific method. Through trial and error, players build a model of the underlying game based on empirical evidence collected through play. As the players refine this model, they begin to master the game world. It’s a rapid cycle of hypothesis, experiment, and analysis.
Think about this when you write your next piece of software – these are the people you are writing software for (after all, most young adults grew up playing videogames). The previous generation read a lot more than they experimented. The new generations try things out first, then collect their experiences and blog about them, then maybe read someone else’s experiences to find kindred spirits. So make your software easy to experiment with, and make most everything undoable.
I am big on flow time. Whenever I am placed in a completely new environment I strive to find a way to achieve the maximum possible flow time.
Here’s a great description of this with an eye to human interruptions, which cites De Marco’s Peopleware and also makes the connection to ESR’s Jargon file.
You should not break without good reason the concentration of a
programmer while they are working. If at all possible, communicate via
e-mail or some other way that lets them react when they have the time.
What follows are some justifications as to why this is so
– Cringe from Crossing a Concentrated Coder, by Lars Wirzenius
But note that this doesn’t stop with people, it happens with your choice on technology and tools as well. I think one of the reasons scripting languages have taken off the way they have is that, since they require little or no waiting between changing the file and seeing the results onscreen, they optimize the available flow time even with basic tools (Most of my rails development is currently done with vim and a shell window).
Stop for a few minutes, take a look at your day to day activities and ask yourself when your flow time is typically interrupted by your tools, and whether you can do something to eliminate that interruption. Good tools are designed to reduce or eliminate the flow time interruptions. Bad tools get in the way of that flow time.
Note that if you’re only learning to use your current set of tools now, you may find interruptions that are just a part of the learning process – those you can write off as learning time, since they will go away once you master your toolset. But if your process or tool forces you to stop your flow constantly, find a way to improve it or use different tools. You’ll be glad you did.
A perfect tool or IDE makes the write-build-test cycle feel so seamless that you forget to think about it, maximizing your flow time.
Finally, note that this optimization is only intended for development time. Your deploy process should still be using build script (i.e., no "building from your IDE" to put in qa or production, please!).
The problem is that our industry doesn’t know how to draw the line between the person dabbling in programming and someone who does it for a serious living. The kid who builds the bird house above would never be hired to build an actual house. Not true in Software Development.The .com era was the perfect example of this. Anyone and everyone was a programmer once they knew HTML. This dillutes how our industry is viewed by the outside world. It keeps us in the ‘geeks w/ keyboard’ box.
I am absolutely in favor of providing the basic logic of programming to non-programmers. It can only help them understand why the requirements they produce need to be carefully written.
The “Geeks with keyboards” worldview is a problem of both sides – you won’t find anybody under 30 who has never touched a computer keyboard (and very few people under 25 who never had to fix a configuration problem on a computer, even if it was just to run Doom), so that view simply no longer applies.
On the other hand, we “geeks” shouldn’t think we’ll never need our people skills because we’ll always be coding and therefore everyone who can’t write kernel drivers or run a windows device driver under the debugger must be a dumb jock. This is an endemic problem in our industry as well.
The Pragmatic Programmers have a great article called Cook Until Done, about the different ways you need to convey instructions, making it difficult to get a “cookie cutter” approach to development. Worth checking out..