How To Be A GREAT Programmer

What’s the difference between great developers and good developers? It’s not about language or tools, it is a collection of other skills and attributes. How to be good at programming is about a lot more than only a good grasp of syntax or an encyclopaedic knowledge of libraries and frameworks. To learn to program well, is something that takes a long time and requires some talent, but the people who are great at it do seem to share some skills.

In this episode Dave Farley, who has worked with many great programmers, describes what he sees as the difference between the people that seem to do a great job and those that don’t. This is about more than only programming tips, but there are some of those here too, and it is not always how we learn to program, it is about how we approach problems and construct solutions that we can live with and evolve over time and how we deal with other people while we are doing it.

-------------------------------------------------------------------------------------
📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------
Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 JOIN CD MAIL LIST 📧

-------------------------------------------------------------------------------------

LINKS:

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[Sergio_Loureiro]

1. Code As Communication
2. BE CAUTIOUS of Frameworks
3. CODE IS DESIGN
4. QUALITY OVER FEATURES
5. Software Development is a Social Activity
6. AVOID CODE OWNERSHIP
7. Work in small steps

[nsicolo]

1. Good programmers spend time and effort in making their code clear.
2. Frameworks are not the core of our skills as professional software developers. Treat frameworks with a degree of care.
3. Design is the choices we make everyday when we write good code.
4. It is the shapes of the solutions that we create what really matters much more than the technologies we choose to implement those shapes.
5. Software development is a social activity. Good developers are also good comunicators: they can express an idea clearly, they can describe complex ideas to other people clearly. Collaborate with people.
6. Great developers are free with their ideas and usually open to having them criticized.
7. Make progress in small steps.

[justinbehnke]

Working in small steps is my favorite on this list. It’s so hard to see the value in the moment, but when you look back on hours of work done and zero time spent debugging, to me that’s a very special feeling.

[sergeixtc]

I gifted myself your new book for Christmas, hope it arrives before the holidays. Really thx for sharing your knowledge.

[TimSchraepen]

One that might be missing is having an eagerness to learn. That is learn about the problem your users are facing and why it matters to them, but also to learn about new technology and softskills like how to give good feedback.
One could say that this skill is incorporated in other items you mentioned, but I thought it’d be worth mentioning more explicitly.

[not-a-doctor]

On a sidenote: I see a lot of nice typography and pretty animation work on the newer videos - good job on the design! Looks very good, keep it up!

[michaeljones]

The article requested at 12:33 appears to be the below

Published: December 1996
Social patterns in productive software development organizations

Brendan G. Cain, James O. Coplien & Neil B. Harrison
Annals of Software Engineering

[AI-xijk]

Let’s not also forget that great programmers don’t have to know everything, but they have developed an ability and grit to dig into the problem, understand why something doesn’t work and come up with a solution while learning about this new topic on the way. Many programmers don’t become great because when they face a hard problem they either look for someone to solve it for them, look for a framework or even worse some kind of workaround. In the end they avoid tackling hard staff and never improve their skills. I think it’s not so much about knowing some language or framework but more about the aptitude. We always have to solve new problems, otherwise we would be just copy pasting code and calling it done. To come up with a great solution you need to not only to think how to make it work but also how it might fail. In the end every team hopefully has at least one person who can always figure out the answer even if he never faced that problem yet. Even greater programmers will communicate their process and decisions to the team to keep the information flow at the right level, be realistic with stakeholders and help others learn.

[Yxcell]

Hello, Dave. Thanks for the thoughtful video(s). It gave me a lot to think about in how I approach software development.

At 6:38 you mentioned that you prefer lightweight frameworks that don't impose their design/architecture too much on the developer. Would you mind sharing a few examples of which kinds of these frameworks you tend to use? I'd like to explore them and try them out to get a feel for them.

Thanks again!

[unicastyourself]

"Programming as a social activity". This is so true. For example, after you've been working some time with microservices and especially if you can explore the landscape, as you cross urbanized areas, wild jungles, derelict, abandoned neighborhoods, both brutish and elegant forms of order, war zones, factories and playgrounds - in fact the absolute opposite of a clock's internals - and learn about (or mostly recognize) the inhabitants communities, it's hard not to end up looking at your job as a form of anthropology or sociology. You get a live reminder about the inherent violence of Nature, even if, just as in physical landscapes, sometimes in the middle of nowhere, you find a flower.
It's interesting to observe that we conceive these virtual worlds in the image of the societies we live in, not necessarily as the one we would like to be a part of. This makes us more slaves than masters I guess. In any case, I.T. is no form of escapism !

[JDLuke]

Liked for shirt. Now it's time to watch what will undoubtedly be a clever combination of stuff I've known for 35 years plus some insights I haven't considered.

I always enjoy your videos, Dave. Your approach codifies and helps me enhance my own and I like that.

[nicolabombace]

10:59 Dave: "Wave your hands around". Italian Me: "That will-a be easy-a"

[jordanweir]

The point made at about 11:35 is a really interesting one that I never thought about, it's like a good time investment to go for quality because all the time its live one day will be time where it's benefiting from the quality that was put into it initially

[TinBryn]

On point 2 (Be cautious of frameworks), I find a great way of dealing with this is an application library model, rather than build your application within a framework, you just have simple calls to your actual implementation which is somewhere else. Yes the framework is still in control and at the top of the application, but that top is small and probably fairly trivial and replaceable.

Although often times frameworks are meta-programming eager and even moving **my** code behind a function call will break the framework. Anything that prevents me from breaking up **my** code how I like gets a hard no from me.

[LaksithaRanasingha]

Thanks for listing these valuable skills in a succint way Dave. I think the ability to translate deep, abstract or ambiguous technical details to non-technical folks (as something easy to comprehend) is a super important skill. I've seen some developers do it by bringing simple examples and mixing with wit/jokes to make non-tech folks more engaged and they grasped it. That could be an extension/part of to the skills "code as communication" and "software development is a social activity" .

[TheJacklwilliams]

Thanks Dave for leading these types of discussions and hopefully, us in a good direction. I ordered your book as well and can't wait for it to arrive. I've got 30 years in the business, my next chapter is coding/dev and will be the way I go out. I've danced around it, did some dev about 15 years ago before getting snagged on a completely unrelated paradigm (wish I stayed then). However, I know fundamentally learning syntax and language is but a small part of the job. I see it as an iceberg, with the choice of language being the part above the water... Great channel, incredible lessons. Thank you for sharing.

[simonolofsson]

Little did I know this video hit literally at home for me, as an author of an Open Source framework for chatbots called Pyttman.
Amazing how you made excellent points as to how locking in users isn’t the real goal with creating a pattern and constraints, but becomes a side effect of offering APIs which fails fast.

I’m currently working on offering lighter options for situations where leveraging the Django-like pattern isn’t necessary or desired by the developer. This video just made me realize how important that is.

[esra_erimez]

I finished your book, and just received the book you wrote with Jez. It i filled with the anecdotes and details I was hoping for.

[MrStefanica]

Very useful! I liked the argument that design is part of the every day's work, also about thinking in terms of shapes. Dave, you are adorable in this t-short! Thanks a lot!

[KulaGGin]

Thx for the book, going to read it.
One of those rare cases, where the video is made not just to promote a book, but a genuine video on the topic and a genuine reference to the book, because it matters.
Got to read Robert C. Martin books the same way.