Find more interesting articles at yos.io
What does it mean to be a true software craftsman?
Here are my highlights from The Clean Coder, a code of conduct for professional programmers.
Do No Harm
Software is too complex to create without bugs.
However, you must be accountable for errors even though errors are virtually certain. Apologies are necessary, but insufficient. You cannot simply keep making the same errors over and over. As you mature in your profession, your error rate should rapidly decrease towards zero. It is your responsibility to get as close as possible to it.
QA should find nothing.
Some folks use QA as the bug catchers. They send them code that they haven't thoroughly checked. This behaviour is just plain lazy and irresponsible. Releasing code that you don't know works is unprofessional.
You must know it works.
Test it. Test it again.
Every time QA finds something the development team should react in horror. They should ask themselves how it happened and take steps to prevent it in the future.
Work Ethic
It is not your employer's responsibility to make sure you are marketable. It is not your employer's responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility.
You should plan on working 60 hours a week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.
Mentoring
The best way to learn is to teach. Nothing will drive facts and values into your head faster and harder than having to communicate them to people you are responsible for.
Good Code
First, your code must work. You must understand what problem you are solving and understand how to solve that problem. You must ensure that the code you write is a faithful representation of that solution. You must manage every detail of that solution while remaining consistent within the language, platform, current architecture, and all the warts of the current system.
Your code must solve the problem set for you by the customer. Often the customer's requirements do not actually solve the customer's problems. It is up to you to see this and ensure that the customer's true needs are met.
Your code must fit well into the existing system. It should not increase the rigidity, fragility, or opacity of that system. In short, your code needs to follow solid engineering principles.
Your code must be readable by other programmers. It requires you to craft the code in such a way that it reveals your intent. This may be the most difficult thing a programmer can master.
3 AM Code
When you cannot concentrate and focus sufficiently, the code you write will be wrong. It will have bugs. It will have have the wrong structure. It will be opaque and convoluted. It will not solve the customers' real problems. In short, it will have to be reworked or redone. Working while distracted creates waste.
False Delivery
The worst thing to do as a programmer is saying you are done when you know you aren't.
Ask for help
Learn how to ask for help. When you are stuck, or befuddled, or just can't wrap your mind around a problem, ask someone for help. This is a matter of professional ethics. It is unprofessional to remain stuck when help is readily available.
Collaboration is critical for effective programming.
Team effort
As a professional it is your job to help your team create the best software they can. Everybody needs to watch out for errors and slip-ups, and work together to correct them.
Meetings
Use your time wisely.
When you receive a meeting invitation, don't accept unless it is a meeting for which your participation is immediately and significantly necessary to the job you are doing now.
When the meeting gets boring, leave. You have an obligation to manage your time well.
Stand-up Meetings
- What did I do yesterday?
- What am I going to do today?
- What's in my way?
Each question should take no more than twenty seconds.
Priorities
Professionals evaluate the priority of each task, disregarding their personal fears and desires, and execute those tasks in priority order.
Swamps
Professionals fear messes far more than they fear blind alleys. They are always on the lookout for messes that start to grow without bound, and will expend all necessary effort to escape from them as early and as quickly as possible.
Keep your systems, your code, and your design as clean as possible.
Commitments
Professional software developers do not make promises that they can't keep, and they don't make commitments that they aren't sure that they can meet.
Craft
A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes.
Find more interesting articles at yos.io
Top comments (21)
All three of "Uncle Bob" Martin's books (Code, Coder & Architecture) are absolute must reads. Some of his talks you can find on YouTube are pretty good as well. I consider him to be among the best software engineers on this planet. Aside from his strange fetish for test-driven development (I personally strongly disagree with the "test first" principle), he is very pragmatic in his decisions.
However, as with all advice which is as general as the content of Martin's books and talks, do take it with a grain of salt, in particular when it comes to details. Perspectives, situations and people differ. His general overarching message that we should all try to become better engineers through discipline, expanding knowledge and asserting quality is the best advice I can imagine.
Sorry but no, very much no! When I'm not at work it is my responsibility to take care of my marriage,my wife, my children, my home and my life in order to be able to come to work well rested and able to focus on work. I simply don't have time for a half time extra job if I want to be good at doing the important things in life. Quality is everything, quantity is useless if quality is lacking.
Luckily my employer and my boss are on the same page as me. That's why I am not keen on looking for a new job and that's also why me or my family never object when my employer needs a little extra from me on the odd occasion. Swings and roundabouts.
Hello,
Personally i think that the 20 hours a week are manageable.
I do an one hour research before and after work.
3 - 5 hours the weekend.
Of course this can be altered to anyone's preference and timeline.
For me its important to do a little reading, but its not a requirement to do for 20 hours. You can adjust it to your liking.
Although i should say i like your opinion based on the time you need to spent with your family.
I would do the same if i had time to do only one thing.
Thanks for your time
If it's manageable for some people, that's great. I'm extremely wary of anyone suggesting that it should be the norm, though, because:
As a soundbite, expecting a 60-hour week isn't a work ethic, it's commitment creep.
Expecting a 60 hour week and paying for 40? Those 20 hours are slavery.
"Personally i think that the 20 hours a week are manageable"
... for you. Don't expect other people's situations to be similar to yours. And be ware of "can't you just" suggestions. They may sound helpful in your head, but they come across poorly.
Hello @Alain Van Hout,
I don't know if you read my whole comment.
But i didn't say that i'm absolute with this but what works for me.
I stated that if i had to choose between family and work (and couldn't do these 2 things together) I would choose family of course.
Please don't be quick on your judgement to others.
I merely said what is on my head and on my daily routine. I don't expect anyone to follow my routine because they don't have my life.
Thanks,
That's good to hear.
I did read the rest of your comment before replying, and even then the first sentence still sounded like an absolute, in the sense that it seemed that you'd expect it to be true for most people -- i.e. barring unusual exceptions.
That's the problem with language I suppose, especially in written form: it's very easy to find different meanings in the same piece of text :).
This is a great suggestion! I agree that 20 extra hours per week dedicated solely to yourself can be a burden. Some other commenter already said here that he spends one hour before the work, and one hour after his work. That's 10 hours during work days. I believe that's already a great achievement. However, that might not be always possible. But that's also ok. To me, the best thing is to be consistent and try to achieve some small thing every day (for yourself, not your employer!). Of course, family and private life is extremely important and should be always more important than professional career IMHO!
I want this to be constructive :D Testing your code, not making commitments you can't keep, being a boy scout in the codebase and leaving it better than you found it are ALL great and classic software engineering rules! Not expecting your employer to be interested in your professional development is not.
It leads to age discrimination (as we get older, outside responsibilities like family, homes, and financial management typically increase), and burnout.
Negative examples are asking for a github in an interview from an engineer that was coding with 3 kids a wife, 2 cars and a yard to mow before github even existed.
No github, no job.
The only way to learn framework X that the employer requires you have experience with is on your own time.
No framework, no job.
10 years of experience with technology Z but since you didn't spend your own time with Z 1.2, no job.
If I spend 2 hours every weeknight after I leave work, eat dinner, and put my son to bed, then I'm faced with the choice of quality time with my wife, coding, or cutting my sleep by 2 hours.
We as software engineers have to fight back against the 'code all day and night' mentality. It's toxic, destructive, it pushes people out of our industry, and the only benefit is to the employers that get to save money on skill development programs by convincing us that we should be doing these things on our own time.
I loved most of this excerpt! But we HAVE to stop telling engineers that they need to give up significant portions of their lives just so our employers can abuse our passion for coding. ('Not passionate enough' is another code-word they use for 'doesn't seem like they would work 20+ hours extra for 0 pay')
(Edit: Wall o'text needed some white space)
"You should plan on working 60 hours a week."
We are a sick society.
I agree with many points in this article - particularly using time wisely, asking for help when necessary and not writing code when tired at 3am.
I'm sorry, but I can't agree with encouraging people to work 60 hours a week - both because I don't believe it's good for our long-term health and wellbeing and because seeing ultra-long working hours as a mark of excellence disadvantages people who are unable to commit to such hours - maybe because of family commitments or health reasons. Such attitudes are likely to be one of the barriers to the greater diversity that the tech industry so badly needs - women, older people and disabled people are most likely to be affected. I think employers should encourage full-time employees to use a portion of their working hours for personal development - I believe this would improve inclusiveness employee morale.
I would recommend some understanding of testing and 'QA' (you won't find it in Clean Coder). Testing is not only about code. This is testing: medium.com/@revelutions/how-cem-ka... . Don't listen to anyone who can't test like that.
I think it's a good idea to write good code. However, that has almost nothing to do with testing the product later. The reason you test later is the same reason you deliver code in small increments to get feedback. '.... involve me and I learn' goodreads.com/quotes/21262-tell-me... When you start using a software that you get ideas about risks.
Test first and test later are not either-or. en.wikipedia.org/wiki/False_dilemma
= #kaner #satisfice #developsense #geraldmweinberg #lets-test #cast #lessonslearned
Link not opening correctly. medium.com/@revelutions/how-cem-ka...
I don't see anyone commenting on the standup meetings approach it describes. This technique of everyone talking about stuff done, doing and blockers almost always ends up being a time waster (you know, the one that blunders their way through it because they haven't been attached to their intravenous coffee drip yet, or the one who doesn't shut up trying to impress how busy they are). Worse, it promotes siloing and demotes pairing. What matters is the work - talk about the tickets/tasks on the board and how they're going to get progressed today. Talk about the important ones like blockers or expedites first, you may not even need to bother talking about the low pointers. Talk about it like a team, not a bunch of individuals justifying their jobs. Praise what you achieved in retro, instead of moaning about how you feel unfulfilled in your job!
Great summary of the book. Appreciate your efforts on condensing it in an easy to read format.
Keep it up 👍
Link wrong?
Fixed, thanks!
If anyone has an extra copy of this book they'd be willing to donate, I would love to consider it for use in my class (Level 7 @ The LEAGUE of Amazing Programmers [jointheleague.org]).
Perfect digest, I could share this with my team. Thanks!
I think this is actually the best programming-related article that I have ever read. Thanks for posting, really good advice :D