Daniel Terhorst North @Tastapod@mastodon.social on X Thread What Do I Mean by “The Best Programmer I Know” Let’s Start With the Assumption I Think I’m a Decent Programmer. Here Are Some Examples 1. He Sees

Daniel Terhorst-North @tastapod@mastodon.social on X: “[Thread] What do I mean by “the best programmer I know”? Let’s start with the assumption I think I’m a decent programmer. Here are some examples: 1. He sees what is really there. I see what I am conditioned to see. Once he points it out, it was obvious all along. https://t.co/dGPzMKfb29" / X #

Excerpt #

[Thread] What do I mean by “the best programmer I know”? Let’s start with the assumption I think I’m a decent programmer. Here are some examples:

1. He sees what is really there. I see what I am conditioned to see. Once he points it out, it was obvious all along. https://t.co/dGPzMKfb29

Post #

Conversation #

[Thread] What do I mean by “the best programmer I know”? Let’s start with the assumption I think I’m a decent programmer. Here are some examples: 1. He sees what is really there. I see what I am conditioned to see. Once he points it out, it was obvious all along.

Quote

Replying to @tastapod and @si13b

Define “best” - for all we know everyone in this thread might have different criteria in what constitutes a good programmer…

[

]( https://twitter.com/thluiz)

2. He solves the problem at hand, not a fancy generalised version of it. 3. He writes simple, obvious code that is easy to change later. 4. He knows he doesn’t know, but tries anyway. He then iterates on his attempts until he gets there. This requires humility and perseverance.

5. He chooses the right tool for the job, even if he hasn’t used the tool before. He figures the investment in learning the tool is worth it to solve the problem the right way. This means he builds simple solutions rather than easy ones. (h/t @richhickey)

6. He knows when to hack and when to invest in quality and makes these choices deliberately. His hacks are still written in a way that they are easy to stabilise later. He builds small, intention-revealing components that can be easily refactored, restructured or replaced.

7. He is generous with his knowledge and takes genuine delight in seeing people learn. He taught me that the learner should always drive in a pair. You feel like you’re going slower but you both get better faster. Note: the learner isn’t always the less experienced person.

8. He doesn’t constrain himself to software. He looks at the whole situation and will happily refactor a process, make physical hardware, build a supporting app, challenge the premise of the problem, whatever it takes. It just happens to usually involve software.

9. He stays informed by plugging into various networks, both public and private, of individuals and groups that challenge and advise each other. 10. He is a net contributor to any group he is a member of. Not just through information, but through encouragement and support.

11. He has the ability to Just Start. I will procrastinate, read the tutorials, gen up, etc. He just goes from stop light to stop light until he is done. [Note: He happens to be male. This is incidental. I know plenty of female programmers with many of these characteristics.]

12. He works really bloody hard at this. There is no “innate programming gift”. The way to make something look easy is to do it again and again and again, and be prepared to be rubbish at new things until you get better at them. This is hard, especially IME if you have a big ego.

13. He doesn’t follow any single method or methodology, but he learns about them in case they may be useful, and so he has context when other people talk about them. 14. Related: He learns languages, tools, libraries, programming styles. This gives him different perspectives.

15. He has interests outside of programming, including physical activities like acrobatics, and takes his family life seriously. This sets a good example to less experienced programmers that they should keep a decent balance. 16. He sends people home at the end of the day.

17. He has amazing attention to detail, but doesn’t take himself too seriously. 18. He is as comfortable designing (awesome) web pages as he is designing (awesome) backend infrastructure and (awesome) distributed architectures. He got good at them by studying them.

19. He watches how people use his software, figures out what frustrates them, simplifies it, and eliminates their frustration. He doesn’t make assumptions about what people want from his software, he asks them and he listens.

20. He studies the business domain he is working in, and its inhabitants, so he can express domain concepts clearly in code and connect them together to solve meaningful problems. /end.