Avoid These Common Mistakes Junior Developers Make!

i think software development is a fantastic profession but i also think that software development is a lot more complex than we often think the trouble is that it's incredibly easy to make mistakes in software not just in the coding that they're common enough but also in how we think about and approach our work there are lots of different kinds of mistake to make but which are the most common in the early stages of your career what are the mistakes that inexperienced software developers often make and what's my advice on how to overcome them [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't already please do hit subscribe and if you enjoy the video today hit like too i'd like to begin by saying thank you to our sponsors harness equal experts octopus and spec flow they're helping us to build our channel so please do check out their links in the description below continuous delivery is helping some of the biggest companies in the world create the best software in the world and they're probably doing it faster than you too whatever the size of your organization or scale of software project i have an online course that will help you to take your software development to the next level with continuous delivery i currently have an offer on my better software faster course where you can get 100 pounds off so don't miss it the link for the details is in the description below in this episode i want to explore my thoughts on eight of the commonest mistakes that junior developers often make the first of these mistakes is software development is all about coding it's obvious why this is such a big deal for devs just starting out after all that's what software devs do right they write code well yes but this is like asking what it is that a carpenter does and answering that they use a tenon saw that is not what they do either of them that's how they do it carpenters make things doors chairs cabinets software developers create software systems that are meant to solve problems for people in some way that is our job solving problems not writing code i love our profession in part because i enjoy the mental focus that writing code gives to me but i get much more pleasure from finding a neat solution to a problem even sometimes if it involves no code at all as a profession we obsess far too much about our tools and don't spend enough time thinking about what we're really paid to do very often instead i recommend that you take more ownership of the problems that you're trying to solve always think would i like to use this software and if the answer is no why is that and could you do something different to change that i've been fortunate enough to work with some great software developers through the course of my career they weren't great because they knew more about languages that they used though some of them did they were great because they had more insight into the problems that they were solving and found simpler solutions to those problems you don't get to be a 10x programmer of whatever that means because you type 10 times faster you're great when you solve problems with less code next in my list of mistakes if only the business could get the requirements right actually i think that this idea almost completely misunderstands the problem of software development it assumes two things the first is that it's a developer's job to write code and someone else's job to tell them what code to write why can't the business simply tell us what the solution is clearly and concisely then we can translate that into that solution into code well it's true many organizations try to make it work this way this is simply wrong if the developer's job was simply a translation exercise from a description that was detailed enough to be correct then couldn't we just automate that translation and effectively turn that correct description into the code itself what then's the point of developers at all the people writing the description would be the developers then no it's much more difficult than that in reality organizing our thoughts so that they are executable by a computer and understandable to a human to a human being is a difficult thing but understanding what users want and what works for them is also a difficult thing the second incorrect assumption is that there is someone who knows the answer to this someone who knows what it should do no one really does there's a lot of data to back this up users don't know what they want if you ask most users what they want their ideas are usually a small step from what they what they already have it's certainly useful to know what our users want but great products surprise users and go beyond their expectations no one was asking for an iphone before it invented smartphones and revolutionized the mobile phone industry no one was clamoring to buy books online or sell their sofa online before amazon in ebay started up the other angle to this is that the companies themselves even the innovative ones don't know the answer either steve jobs and apple thought that the newton and the lisa were great ideas they weren't data from a study in microsoft said that two-thirds of software product ideas created zero or negative value for the company that creates them so when your boss says we've got a great idea for a product she's guessing we are all guessing and so our job is to develop systems in a world of uncertainty this isn't because somebody is stupid or evil or doing a bad job it's simply the nature of the game what this means is that we need to work in ways that protect us from bad guesses we need to figure out how to incrementally evolve solutions to problems over time to grow them step by step and so give ourselves freedom to make mistakes next in my list speed is all that matters i think that a focus on the wrong kinds of speed takes a variety of forms to go fast we need to work smarter not harder there is a trivial way in which junior programmers focus on speed sometimes makes me as a somewhat grumpy old man smile internally when i see it this is typing very fast i've often sat with more junior programmers and watched them dash around changing stuff so fast that i struggle to follow that may be me being old and slow but it's also them not allowing themselves or me time to think being a good typist and knowing your tools well enough to move around efficiently is certainly a good thing but if you are hoping that typing speed will improve your performance you're optimizing the wrong part of the problem our aim should always to be to write less code so pausing and thinking about alternative ways forwards is always a good idea draw a picture have a chat think about what comes next and then start typing the other way to that speed fools us is chasing the delivery of features nearly all of the organizers that i see seem to optimize work to ensure that everybody's always busy this i am afraid is a rather naive view of how to go fast software development is an intellectual creative discipline our real goal in software development is learning that's the expensive part not the translation of that learning into code once the problem is clear the coding is easy if the coding is hard that is nearly always because you don't understand enough about the problem making the problem clear is the hard part one of the reasons that i value tdd quite so highly is that it's the best way that i know to learn what works quickly my advice is to optimize for learning not the rate of feature production next in my list my job is to code not to understand the problem domain this is somewhat related to the first mistake in my list but it's a little different one of the most important things to learn is about the problem domain that you're working the best programmers that i have known are fantastic at picking up this kind of knowledge and the converse is true however well you know your programming language and programming tools if you don't understand the problem that you are working on in some depth you will do a poor job you don't have to be a domain expert in some ways it's worse than that the best programmers know the problem domain well enough to have domain insights that even experts sometimes miss we won't have the same kind of domain expertise as a true domain expert and knowledge will often be a little bit more surface but if we're doing well we will spot similarities and opportunities that domain experts miss because they are too close to the problem so pay attention when people are talking about the problem domain work to establish a common language that you can share with domain experts to explore and explain problems ask them for clarifications if you don't understand some concept try and see the real problem in the real world if you can this will have a deep impact on the quality of the code that you write on its simplicity readability and on your ability to grow it as your system and understanding grow next in my list i can't ask for help it shows that i don't know enough this is an imposter syndrome mistake it takes a certain amount of self-confidence to ask questions the truth though is that the more that you know the more that you know that you don't know enough smart people ask questions dumb people think that they have all of the answers i think that to be great as a software developer you must become comfortable with uncertainty because there isn't much certainty to go around to be honest ask questions if a dumb person thinks that you are dumb for asking questions that's their problem not yours the point at which this is not true is if you ask the same question over and over again i have a little trick as a suggestion that you might like allow yourself the freedom to ask a question twice if you want to ask a third time take the person with the answers aside fess up that you don't understand and ask them for some help nine times out of ten they will help you and think better of you for doing this next in my list software architecture is for the experts designing a good architecture takes experience i think that you need to have seen similar things done in at least three different ways ideally three different technologies before you really have that kind of experience but software architecture is about more than only creating it a good software architecture is a bit like a tourist map of a system it shows you enough to find your way around without going into too much detail that you can't so that you can't find out where you really are when i used to do a lot of interviewing i used to ask developers to describe a system that they knew or worked on my aim was to see how they thought about systems rather than caring about what the system actually did or how it did it a significant proportion of developers when asked this kind of question simply lists the technology it was a java system running on tomcat with an oracle backend okay but what did it do and how did it do it i think that any developer should be able to describe how the system that they work on works ideally to a non-technical person but at least to a technical person who doesn't know anything about the system it's a good test could you explain it to a friend or to your non-technical grandma what are the organizing principles in the system that you're working on that really matter what ideas help you to decide where to place behaviour in your system what's the tourist map for your system next in my list testing is someone else's job if you write code how do you know it works even if you write code without automated tests then presumably you run it first to see if it works if not then you're dangerous and need to take a step away from the keyboard so now our only debate is whether our testing is automated or manual if you're a regular here i don't want to bore you too much by repeating myself if you're not a regular check out some of my other videos on test driven development and behavior driven development to see why the correct answer is automated testing so now who should write the tests well mostly it's us developers we are the people that write code that can break to the tests we are the people that will need to fix the code if it goes wrong so we are the people that should see that mistake first and be best placed to understand it and correct it for that we need to at least own responsibility for the tests that are running and most of the time with best place to write them ourselves to remember our job is to solve problems not to write code how can we tell that the problem is solved without checking to see if it is the last in my list i would do a better job but my boss won't let me this is a big but common mistake it can be a cultural problem in poor organizations and fixing it can feel uncomfortable to fix it relies on some self-confidence again that may be hard to find at the start of your career but at some level at some point we must take responsibility for our own work if you hire me as a chef you're making a big mistake but if you make that mistake you wouldn't expect to have to tell me to clean up as i worked you'd assume that i would keep my work area clean and my tools sharp as part of my everyday work you wouldn't ask me how long to cook a good meal and expect me to answer well i can do it in 20 minutes as long as you don't expect to use the kitchen again but in software we do sometimes provide those kinds of answers if you've ever given an estimate that didn't include refactoring or testing you did this if you've ever skipped these things to hit a deadline you did this there is a professional duty of care here that we are all responsible for we are the experts at our profession i don't think that we should be asking other people permission to do a decent job so those are my eight pieces of advice about focusing on the right things inevitably you'll be working in an existing team with existing norms of behaviour as a junior member you may not be in a position to exert authority and demand that other people change my advice then is to do what you can try the soup exercise that i know curry mentioned in an earlier video identify the stuff that is within your control and change those things for the better identify the things that you can influence and you may be surprised at the influence that an enthusiastic newcomer can exert on a team as long as you try to change things by demonstrating better ways of working and encouraging people rather than demanding action from others it's better to ask for forgiveness than it is to ask for permission finally recognize that some of this stuff is beyond your control and influence and so focus on the stuff that is and do a good job of that thank you very much for watching [Music] you

Channel: Continuous Delivery

Views: 89,692

Rating: 4.9619265 out of 5

Keywords: junior developer, tips for junior developers, junior developer need to know, best junior developer tips, new developer advice, common software mistakes, junior developer mistakes, first day as a junior developer, what to avoid as a junior developer, advice for software engineering students, devops, Continuous Delivery, software engineering, software development, Dave Farley

Id: 5g3dK2DgW-k

Length: 17min 54sec (1074 seconds)

Published: Wed Apr 28 2021