How To Be A GREAT Programmer

software development is a difficult thing to do well we need to learn about the problems that we're trying to solve to make good use of the tools at our disposal solve

problems that are at least sometimes world-class complex occasionally maybe even breaking new ground we deal with this flaky hard to understand stuff that doesn't really

exist and that is so weird so fragile that a tiny misstep can lead to disaster we need to work with groups of other people and grow these complex useful

systems bit by bit sometimes over long periods of time so what are the skills that it takes to do that kind of thing what are the skills that you need to be

a great software developer [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the video

today hit like as well thank you to our sponsors harness equal experts octopus and spec flow they're helping us to grow our channel so please do check out their links in the

descriptions below my new book modern software engineering talks about what it takes to build great software quickly and efficiently

it's on sale now and there's a link in the description too for this episode though i want to look at this from a more personal perspective i guess

i've been fortunate enough to have worked with some world-class developers during the course of my career and met many others who are well known and well respected in our industry

i think that there are some common maybe not universal but common shared characteristics i don't have any data to back these

opinions up so they are only my opinions but here they are with my view on the six important characteristics of great developers

number one code as communication i think that when we think about writing code we often imagine ourselves as communicating with

a computer and and to some degree that's clearly true but it isn't our primary objective computers unless you're doing something weird with quantum computers talking

bits on or off so the most efficient way to talk to a computer from its perspective is to flip some switches in fact in the earliest days of

computing this is pretty much how things worked even as late as the 1970s punch cards with holes or not holes represented the value of a bit

we've moved on from there that's not how it works anymore these days the target of our communication when we code is other people not the computer of course our

code needs to work but all modern computer languages are focused on how we think rather than how the computer works then they translate our ideas into an

executable form that our computers can work with this means that we should take care to communicate well the readability of our code is not a

nice to have it's an investment that saves time and money often the person that you want to be able to read the code is you in the

future so good programmers spend time and effort in making their code clear code that communicates the ideas that it embodies effectively and concisely a few

tricks to achieve this are to pick clear descriptive names for modules functions and variables pick names that allow you to make little sentences that make sense keep modules and functions small and

focused on a single task aim to write code that anyone could read and then be able to understand what's happening in their narrow focus in just a few seconds

next in my list is to be rather cautious of frameworks frameworks are useful tools but they are ephemeral they change all of the time

and are not the core of our skills as professional software developers this means that there are risks to using them if the design and structure of your code

is determined by a frame the frameworks that you choose that means that your code will need rewriting if the framework changes or if you decide to migrate to another

this is often maybe even usually a big enough cost that is going to put you off the move so in general we'd much prefer it if we could control the overall organization

of our code allowing us the freedom to change it as our understanding grows as our needs change or as we realize that we made a mistake in our choice

the problem is with this advice is that many software products make this difficult if not impossible there's a somewhat cynical view that this is in the interest of the framework

providers to lock you into their framework there's certainly truth in this but at least for the open source frameworks i don't think that is their primary

motivation rather it's that it's easier to imagine how to make people's lives easier with your great new framework if you place limits on the structure and

programming model that your users need to employ if you can force people to write their code that uses your framework in a specific way then it makes your

life as a framework creator simpler this is so true that it is really what defines a framework rather than a library my code uses a library but my code is

structured by a framework so by definition a framework imposes structure on our code that tends to lock you in i'm not suggesting that all your code

should be so generic that it will work with any old framework that's a big cost not worth spending rather that you treat frameworks with a degree of care

think about the degree to which they force their programming model on you some frameworks ask less of your code others more i prefer the ones that ask

less how much of your code is framework specific is a good question to ask how easy or not would it be to keep the core of your code the parts that really define the value of your system

clean of any framework defense dependencies for example in general i prefer frameworks with a rather light touch in fact i usually prefer to retain full control over the

programming model and structure of my code and so tend to pick frameworks or libraries that will allow me to do that my preference whenever i can is to

isolate any third-party code behind my own abstraction of its function i'm not going to work hard to make that abstraction completely generic

it's just has to stop the third-party code from leaking too far into mine that way i have just a bit more choice if i need to change my mind in future

there are times and technologies where this isn't possible or at least too costly in terms of effort for me at least though i treat these sorts of frameworks with much more suspicion i

accept frameworks like this only if they give me something really really important that i can't get any other way even so i will try and limit the radius

of their influence within my code as far as i'm able to next in my list coding is designing it seems to me that we often talk a lot

more about tools and technology than we do about design i was in a conversation with someone recently we were discussing how to solve a problem that they had and how the

system could work to deliver some feature i was describing it in terms of the information in the system and how it flowed between different modules and the sorts of things that we that the modules

would need to say in conversations between them they kept translating it into features of kubernetes and helm charts

first i'm not a kubernetes expert second that wasn't really what we were talking about and third it seems to me that they were confusing the accidental complexity

that kubernetes manages with the essential complexity of the problem that we were talking about solving this seems quite common to me often if i ask people how their systems

work most will respond with a list of technology that tells me very little about their sys how their system actually works it is the shapes

of the solutions that we create that really matter much more than the technologies that we choose to implement those shapes

how we choose to divide a problem up how we decide where it where it makes sense to add some new behavior to the system i talk about this in my new book as focusing on managing the complexities of

our system and it is but the other word for this is really just good design i don't see any distinction between coding and design

design is not the job of some clever person in an ivory tower somewhere it's the choices that we all make every day when we write good code the good is important here because

there's quite a lot of code out there that has no visible design at all this is true at the tiniest level of the code within a function and at the biggest of scales for some globe

spanning system design is the collection of organizing principles that we choose to apply to the code that we write and the systems that we build

those organizing principles help us to compartmentalize the problem and manage that complexity it's fundamental to our discipline and more than any other characteristic that

i can think of it's the thing that distinguishes the great developers from the not so great all of the best developers that i know focus first and foremost on the

information that we are dealing with and how we deal with it in terms of the protocols through which information is exchanged between different parts of the system they may not always think of it in those

terms but i think that's what they're really doing how that maps onto the technology is a separate and ultimately a smaller part of the problem

try to visualize what you are really trying to achieve without referring to the technology that you expect to use to achieve it draw a picture it doesn't need to be formal

talk about the ideas use sticky notes or wave your hands around but think first in terms of the shapes that you will need to create and the conventions and the conversations that they will need to do

the job only then think about the technology next on my list of things quality over features

good programmers take pride in their work this is not some gold plated over engineering this is practical and pragmatic they aim to retain and sustain

their ability to make change effectively and efficiently over the long haul most software spends much more of its time in use than it does in initial development

estimates comparing the amount of work in initial development to the amount of work spent keeping the software up to date and working after release range somewhere in the range from 60 to 80

percent in the favor of maintenance this is probably even more skewed towards change after the first release if you adopt incremental approaches like continuous delivery and agile development

so that means that great software developers will optimize for that long haul they will work hard to build high quality now because they know that that

will reduce the likelihood of rework spent fixing dumb bugs in the future and it means that when they need to revisit their code in the future months or years later it will still make some kind of

sense to them next in the list professional software development is a social activity there was a study that i can't find a

reference to if anybody knows of it and has a link please do let me know but the study was meant to identify the characteristics of great software developers

the only common characteristic that they could identify in these ide these developers that were that were categorized as great by their colleagues in the study was that these great

developers talk to other people more often most professional software development is carried out in teams even if you are working alone in the code you're usually working with other people that will

describe the problems that they want you to fix so software development is a social activity so sure there's probably some truth in the caricatures of us

being nerds at least for me but they are overblown the best software developers that i know are good communicators some of them are sometimes socially

awkward in some contexts aren't we all but they can express an idea clearly and they can describe even complex ideas to other people clearly

this is importantly related to the first idea in my list code as a communication if you find it hard to express your ideas clearly in conversation or in a diagram what are the chances that you're

going to be able to write good code there's a lot to this and so a lot of ways to tackle it it helps to teach others you learn from that experience

one of the reasons that i value pair programming quite so much is that it forces us to have conversations about code and to learn from one another you can say the same for code review if you

are struggling with a solution or an idea go and explain it to somebody else you'll be amazed how often you'll solve the problem before you've even finished explaining it

maybe try writing a blog even with if a few people read it it will help you to organize your thoughts develop your writing and so grow your communication skills

collaborate with people on tasks at work offer them your help to maybe join a user group or a meetup group that talks about things that you're interested in software development really doesn't

thrive in a vacuum the idea that a lone genius hacking away in a basement is largely a myth there are times when you will benefit

from working alone with some deep focus but don't overplay it and try to find ways to often bounce ideas off other people next in my list avoid code ownership

the great developers that i've seen are free with their ideas and usually open to having them criticized they may not always seem like that at first they'll defend their ideas vigorously but will

always be open to learning something new if you can show them they are not precious about their code just because it is their code i confess this may be one of my more

idealistic takes but it's certainly true for all of my friends who i consider to be genuinely great programmers in professional settings i see it as an anti-pattern for an individual to own

sole responsibility for an area of the code at the minimum responsibility for any given area of the code should be shared by the team

we want people to criticize our ideas we want to be able to get new and different perspectives and different inputs there may be one person

on a team who is the go-to person for the keeper of a flame for any particular part of the system but if they don't allow anyone else to touch the code then that is certainly a problem

the last in my list and in many ways one of the most important ones is to work in small steps the best programmers are generally very bright they're smart people they can

hold a lot in their heads at the same time they can discuss big complex ideas but they make progress in small steps checking each step as they go

i believe that by far the best way to organize this is with test driven development but even when not great programmers make a small change and then they check it

they're usually expert in the fine-grained skills of refactoring making tiny changes that allow them to mold and reshape the code to suit the current pit their current picture

working in small steps is one of the most important ideas in doing a better job in software and optimizing to get fast high quality feedback is the reason if we proceed in small steps we can

learn more quickly it allows us to proceed with more confidence to explore our solutions continually judge them and so refine and improve them so those are some of the things that

i've spotted in the developers that i admire if you have more suggestions do let us know in the comments below and thank you very much for watching [Music]