January 15, 2014 at 11:02 am
I'm currently reading a book that beautifully covers the ideas expressed in this editorial.
Better: A Surgeon's Notes on Performance
by Atul Gawande
Link: http://amzn.com/0805082115
From my perspective, a programmer better meet the minimum requirements of the boss for time and money and quality. I make mistakes but I generally only make them once. I have checklists, templates, and standard operating procedures that I update after each mistake to prevent it happening again.
In my experience, there is a vast difference between programmers. Code may meet minimum standards but one person's code will continue working while other parts of the system change. And one person's code will have excellent clarity and ease of maintenance.
Of course, the best code is no code. If you can generate code or convert it to declarative constraints, you are far ahead of the custom coders.
January 15, 2014 at 11:05 am
Tom Bakerman (1/15/2014)
Luis Cazares (1/15/2014)
In my experience, doing just enough to complete a job has resulted (most of the times) in errors that require extra work and more time invested than just doing it right in the first place.
Companies and managers should understand that quality work requires an adequate time and working 20 hours a day won't increase productivity.
I would claim that in this situation, the person did NOT do just enough to complete the job. If the results are incorrect, then the job is not completed. If I put wax on a piece of furniture meant for outdoor use, it doesn't matter how good a craftsman I am, the piece is not "fit for purpose".
If someone was responsible of backing up a database and just created a backup, then that person did just enough to complete the job. If he validated the backup by fully restoring on a different instance, then he was being professional and went over the bare minimum.
If we keep making excuses to do the bare minimum, we'll never get the opportunity to get a "craftsman job".
January 15, 2014 at 11:43 am
below86 (1/15/2014)
I agree that I've looked at what I've done 2/5/10 years ago and think "what the 'H' was I thinking". And yes you would love to go back and fix it, if you had the time. But I guess I look at it a little different. What takes me 30 minutes to do today may have taken me several hours(or days) to do before. Does that mean it is poorer 'craftsmanship'? Not to me, it means I'm honing my craft. And I'm sure 2/5/10 years from now I'll look back at what I did today and say "what the 'H' was I thinking". But it will also mean it's been working for 2/5/10 years. So what does that tell us about the work?
But... if you're working on honing your craft... aren't you then a craftsman, or striving to be one, and wouldn't that mean you're pushing back on something that you fundamentally agree with?
And just because something has been "working" for 2/5/10 years doesn't mean it is working well, isn't intermittently causing pain, isn't carrying a load of technical debt, or all of the above. There really is a difference between good enough and "good enough." A large part of being a craftsman (or again, striving, always striving) is the ability to spot that difference.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 15, 2014 at 11:49 am
I ran into a concept few years ago:
You always have a choice:
[font="Courier New"]1. Good
2. Fast
3. Cheap[/font]
Pick any two.
I've introduced the concept to my managers as well. Even being a salaried employee along side my co-workers, if you want it good and fast from me you'll have to pull resources (other employees) to cover the rest of my tasks.
I think it also applies to the craftsman or being a professional. You learn to evaluate solutions and pick which way you want to go on it. I had to create an ETL tool with about a 3 week heads up on a DB I was barely familiar with. That meant I had to dump a bunch of stuff on others.
But then I have talked to co-workers at my past job and have found some of the apps I built there are still in use, with tweaks, more than five years after I built them. That means I took the time to build a good but some of it was not fast because it was in the learning curve for me.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 15, 2014 at 12:25 pm
It's wierd, but when I saw the title to this article I had thought this would be chasing a different concept. One where we SHOULDN'T be craftspeople, because right now we still do tremendous amounts of custom work for (after a few dozen companies) relatively similar processes. There's almost no standardization. But that's a different rant, and a different topic altogether.
As to the topic, Steve, your definition of craftsperson seems to change a bit from what's in the article to what you've clarified here. I agree, in general, with your revised viewpoint. I don't agree with the concept overall.
Here's the thing. You're dang right I do work 'just good enough' for the task at hand. I bring all the knowledge and training I've had so far to make it as sturdy and robust as I can without advancing the scope of the process to no purpose other than making it beautiful. To paraphrase a quote from Gail that comes to mind: "Code it the simplest way possible, then adjust for problems."
Do I take two extra minutes and see if there's a better indexing scheme than the one I originally implemented near the end of a project? Sure. Do I overhaul all the code to determine the exactly perfectly performing set? Hells no. Not unless there's performance problems. I don't have that kind of time and I assume the rest of you don't either.
As to training, unless your company is willing to provide for it, it's either expensive in cash or time. I can replace cash. I have a life, as I know many of you do as well (kids, wives, gfs, soccer clubs, string theory research, whatever). I learn as I go and apply it as I go. To Grant's point, of course there's work I did x years ago I could probably have written better with the knowledge I have now. Is it working successfully? Is it causing a significant drain? If the answers are yes and no respectively, it's still "Good Enough".
95% of our work is drudge work. Writing up procs, analyzing optimization plans, determining why poor code is running poorly, and building out schemas and architectures in sane methods. Once you've got the basics to cover most of that, everything else you learn seriously drops out of the 80/20 rule. If something catches your eye AND you can see an application for it that you'll have time to implement, sure, you go learn something new. In general though, to borrow an earlier example, I have little reason to go learn how to perfectly round a corner for high end furniture when I spend most of my days assembling IKEA parts. It's a waste of my time and the company's money unless it can be built at equivalent cost (or for MUCH higher ROI) than the generic stuff. Sometimes there's value there. Most of the time there isn't.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 15, 2014 at 12:43 pm
Well said Craig. This is the point I was trying to make. I need to hone/work at trying to be better at expressing my thoughts into words. Or just wait for others to reply and agree with them. 🙂
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
January 15, 2014 at 12:57 pm
below86 (1/15/2014)
Well said Craig. This is the point I was trying to make. I need to hone/work at trying to be better at expressing my thoughts into words. Or just wait for others to reply and agree with them. 🙂
I guess I can agree too, and it probably also matters what code you are actually creating. I've had code continue to run without maintenance, its not impossible.
Your comments reminds me of a quote from the book "Soul of a New Machine" which is an awesome read by the way, engineering manager Tom West had it on his wall, the quote reads "not everything worth doing is worth doing well," and since the book tracks the development of an at the time state of the art new line of computers, clearly they were doing complicated work where questions of quality clearly came into play. The architecture design clearly meritted desire for quality because this design would be exposed to the systems programmers who's work would THEN be exposed to application programmers, etc etc, but there were plenty of areas of the design that you just didn't have to make beautiful, and as always, "shipping is a feature" like Mr. Spolsky offers.
edit: http://www.joelonsoftware.com/items/2009/09/23.html Joel Spolsky's article which might be on topic here.
January 15, 2014 at 1:48 pm
Thank you Craig, exactly what I was trying to say as well.
January 15, 2014 at 2:27 pm
Evil Kraig F (1/15/2014)
As to the topic, Steve, your definition of craftsperson seems to change a bit from what's in the article to what you've clarified here. I agree, in general, with your revised viewpoint. I don't agree with the concept overall.Here's the thing. You're dang right I do work 'just good enough' for the task at hand. I bring all the knowledge and training I've had so far to make it as sturdy and robust as I can without advancing the scope of the process to no purpose other than making it beautiful. To paraphrase a quote from Gail that comes to mind: "Code it the simplest way possible, then adjust for problems."
Perhaps I didn't express it well enough originally.
However I'd say what you've described is craftsmanship. Craftsmanship isn't perfection. It is elegant, it can be simple, and it's about caring to make it something you're proud of, given all your experience.
I'm not advocating more time, more effort than necessary, but more than the bare minimum you could get by with. I'd argue that when you write code you can walk away early, knowing it will function, but might have issues or will be "creaky" in situations. Or you might spend 2, or 5, or 60 more minutes structuring things to work a little better.
January 15, 2014 at 3:47 pm
I have worked with many in the past who did just enough to get by and rarely pushed themselves to provide anything beyond the bare necessities. I was always the annoying coworker who was sending them links to articles on new functions and bits of code that would allow them to do things better (more efficiently, more eloquently, etc). They would rarely respond and whenever I saw their output, it was obvious they never cared to check out anything I sent them. I was usually putting extra effort into rewriting old processes that were performing poorly while they were checking out sports scores or reading the paper. Eventually most of those employees were let go as their lack of care caught up with them.
I was hoping that getting rid of those who weren't trying very hard was becoming a trend but it doesn't sound like that is the case. I guess I am lucky that everyone on my current team is working towards being craftsmen and not just amateurs.
January 15, 2014 at 4:02 pm
KWymore (1/15/2014)
I have worked with many in the past who did just enough to get by and rarely pushed themselves to provide anything beyond the bare necessities. I was always the annoying coworker who was sending them links to articles on new functions and bits of code that would allow them to do things better (more efficiently, more eloquently, etc). They would rarely respond and whenever I saw their output, it was obvious they never cared to check out anything I sent them. I was usually putting extra effort into rewriting old processes that were performing poorly while they were checking out sports scores or reading the paper. Eventually most of those employees were let go as their lack of care caught up with them.I was hoping that getting rid of those who weren't trying very hard was becoming a trend but it doesn't sound like that is the case. I guess I am lucky that everyone on my current team is working towards being craftsmen and not just amateurs.
I don't remember seeing you at my old organization, let alone getting all those cool emails.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 15, 2014 at 4:04 pm
Grant Fritchey (1/15/2014)
KWymore (1/15/2014)
I have worked with many in the past who did just enough to get by and rarely pushed themselves to provide anything beyond the bare necessities. I was always the annoying coworker who was sending them links to articles on new functions and bits of code that would allow them to do things better (more efficiently, more eloquently, etc). They would rarely respond and whenever I saw their output, it was obvious they never cared to check out anything I sent them. I was usually putting extra effort into rewriting old processes that were performing poorly while they were checking out sports scores or reading the paper. Eventually most of those employees were let go as their lack of care caught up with them.I was hoping that getting rid of those who weren't trying very hard was becoming a trend but it doesn't sound like that is the case. I guess I am lucky that everyone on my current team is working towards being craftsmen and not just amateurs.
I don't remember seeing you at my old organization, let alone getting all those cool emails.
😀
January 15, 2014 at 5:57 pm
Chiming in a little late I know, but FWIW.
This comes back to a couple of rules that are surfaced very clearly in some of the Agile frameworks, but are still ignored fairly routinely.
1. Define "done". - When you say that you are "done" what do you mean? Tested? Documented? Built? Performance Tested?
2. "Good enough" is good enough. Getting that last few seconds of runtime optimisation on a report that is generated once per week is probably overkill!
When you combine these two, you get an infinitely variable scale along which you can place your releases, from the quick and dirty "I need to do this thing right now and will (probably) never have to do it again", to the "Completed piece of functionality which will be installed on a website used by thousands".
Ultimately, this all comes down to recognising that even a craftsman will scale his efforts to the requirements.
I prefer to think of a craftsman as someone who takes pride in his work, and is not ashamed to stand up and say "Yes, I did that". Based on that definition, I do consider myself a craftsman.
January 16, 2014 at 4:47 am
Luis Cazares (1/15/2014)
Tom Bakerman (1/15/2014)
Luis Cazares (1/15/2014)
In my experience, doing just enough to complete a job has resulted (most of the times) in errors that require extra work and more time invested than just doing it right in the first place.
Companies and managers should understand that quality work requires an adequate time and working 20 hours a day won't increase productivity.
I would claim that in this situation, the person did NOT do just enough to complete the job. If the results are incorrect, then the job is not completed. If I put wax on a piece of furniture meant for outdoor use, it doesn't matter how good a craftsman I am, the piece is not "fit for purpose".
If someone was responsible of backing up a database and just created a backup, then that person did just enough to complete the job. If he validated the backup by fully restoring on a different instance, then he was being professional and went over the bare minimum.
If we keep making excuses to do the bare minimum, we'll never get the opportunity to get a "craftsman job".
Nope. A backup is not complete until it is validated.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 16, 2014 at 6:34 am
For all those who think that you shouldn't be striving to do a better job (NOTE: I didn't say always going to absolute perfection), I have to ask this: Have you looked at code you wrote 2/5/10 years ago? If so, are you looking at it and saying, "Yep, good enough" or are you looking at it and spotting issues that you would love to address if you had time because, as I usually refer to myself, old me was an idiot, and he really didn't know what he was doing.
My response to Steve is based on the fact that he works at a great company that values quality software and cares about their employees. Some of us may not...
It's great to preach quality to the masses when you don't have to deal with their realities. Of the developers in my division, I'm the go-to-guy. I get the hard and nasty problems, solve them and leave documented, designed code behind for my colleagues. I get rewarded with worse projects that no-one wants to do and no-one cares about the code or data quality, as long as crazy deadlines are met. It's positively Sisyphian and moral killing.
So maybe it's not the developer or DBA or craftsman. Maybe it's their clients or managers that make the timelines or budgets that decide the quality.
Viewing 15 posts - 31 through 45 (of 58 total)
You must be logged in to reply to this topic. Login to reply