{"id":216,"date":"2019-04-04T09:35:23","date_gmt":"2019-04-04T13:35:23","guid":{"rendered":"http:\/\/soul-repairs.com\/?p=216"},"modified":"2019-04-01T09:21:05","modified_gmt":"2019-04-01T13:21:05","slug":"it-doesnt-have-to-be-perfect","status":"publish","type":"post","link":"https:\/\/soul-repairs.com\/blog\/2019\/04\/04\/it-doesnt-have-to-be-perfect\/","title":{"rendered":"It Doesn\u2019t Have to Be Perfect"},"content":{"rendered":"

In a previous post<\/a>, we talked about how important kitty typing and determination are to technical execution. An important addendum\u00a0to this is that whatever you do doesn’t have to be perfect.<\/strong><\/p>\n

Now, the first response to that is most likely to be an objection:<\/p>\n

You: But…Laine and Josh, quality is so important<\/strong> to companies! It’s like, job #1: don’t mess it up<\/strong>. How can you say that it doesn’t have to be perfect? \"\"<\/a><\/p><\/blockquote>\n

<\/p>\n

Nope. Sorry. Perfection is BAD.<\/h2>\n

First of all, nothing is perfect<\/strong>. Perfection is not a reasonable goal. There is no perfect software.\u00a0<\/em>(for the record, we both tend to fall into the perfectionist trap, so…we don’t say this lightly…)<\/p>\n

Second, aiming for perfection before delivering software is a waste of time<\/strong>. There is a point of diminishing returns inherent in perfectionism – see also phrases like “analysis paralysis.” You need fast feedback, you need to know if what you’re doing is working, and you can’t wait until you know it’s perfect – because that will be forever<\/em>.<\/p>\n

Finally, there’s an advantage of being imperfect that we’ve found very valuable – when people have to fix your code, your processes, your work<\/em>, they have to learn the systems they’re fixing<\/strong>. They have to understand what you did and why.<\/p>\n

You: Well if you did it perfect in the first place, it wouldn’t need fixing now would it? \"\"<\/a><\/p><\/blockquote>\n

Yes, sassy reader, you would think<\/em> that would be true – but the problem is that technology and requirements change so quickly, and businesses must respond if they want to remain in business, so…all code has a shelf life. It will need to be modified, and sometimes fixing someone else’s mistakes is the best way to learn how the system works.<\/p>\n

Leave behind a smooth road. Also artifacts.<\/h2>\n

Since you will<\/em> make mistakes, and that’s okay<\/strong>, you should try to leave as smooth a path to success as possible in your wake. You aren’t going to live forever, and that means that someone will work on your code when you aren’t there anymore to explain it.<\/p>\n

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
\n– Brian Kernighan, The Elements of Programming Style<\/a><\/p><\/blockquote>\n

Write simple code that does one thing well, use good design principles, and make it easy for people who have to fix your bugs or modify functionality later.<\/p>\n

And since someone’s going to be maintaining your code, leave behind entertaining artifacts <\/strong>– comments and function names, documentation and anecdotes for processes. Brains work better when they’re amused – we’re pretty<\/em> sure this is probably science? It’s definitely true for both of us – so leaving behind awesome artifacts helps both the person writing the code\u00a0and<\/em> the person later reading it.<\/p>\n

Mentorship and Community<\/h2>\n

One of the best things in the world is to have someone take a thing you love and make it better<\/strong>. We are none of us as good individually as we are within a community of people with complimentary or supporting skills and talents. Josh likes to do a good job quickly, make it work well, and innovate rapidly. Laine likes to dig into the puzzle of a system, learn how it connects to itself and also other systems, and improve the things that don’t make sense. We both can <\/em>also do other things and work in other capacities, but eventually we exhaust the value we add. Ideally, we leave the systems we love to people who will continue to love them.<\/p>\n

One of the ways that people continue to love the systems we loved is to take what we did and make it better – clearer, or with a more elegant solution. More functionality, or better performance. These are nerd love languages<\/strong>. Changes like these can very much mean, “what I did was worth making better and oh look,<\/em> you did<\/em>.”<\/p>\n

If you teach the people who replace you<\/a> the skills they need to do better than you ever did, that’s successful leadership<\/strong>. You should be proud<\/em> when someone eclipses you – it means that you gave the people you lead or mentored permission to stretch to the fullest of their abilities, and that you embraced the ways that they<\/em> made you<\/em> better.<\/p>\n

The beauty of working as part of a community is that you don’t <\/em>have to be perfect. That community, and the people you and they teach, will come along after you and make things even better than Perfect You could have done.<\/p>\n","protected":false},"excerpt":{"rendered":"

In a previous post, we talked about how important kitty typing and determination are to technical execution. An important addendum\u00a0to this is that whatever you do doesn’t have to be perfect. Now, the first response to that is most likely to be an objection: You: But…Laine and Josh, quality is so important to companies! It’s … <\/p>\n

Read More Read More<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[37,40,4],"tags":[59,54,62],"wf_post_folders":[],"coauthors":[11,26],"class_list":["post-216","post","type-post","status-publish","format-standard","hentry","category-community","category-people","category-technology","tag-execution","tag-kitty-typing","tag-this-is-fine"],"_links":{"self":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/comments?post=216"}],"version-history":[{"count":9,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/216\/revisions"}],"predecessor-version":[{"id":2695,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/216\/revisions\/2695"}],"wp:attachment":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/media?parent=216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/categories?post=216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/tags?post=216"},{"taxonomy":"wf_post_folders","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/wf_post_folders?post=216"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/coauthors?post=216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}