Do you have any other tips for developers at the start of their career? DROP THEM IN THE COMMENTS BELOW! 👇

*Timestamp* 1:50 1. "SW Dev is all about Coding" 3:50 2. "If only the Business would get the requirements right!" 7:08 3. "Speed is all that matters!" 9:22 4. "My Job is to Code, Not to Understand the Problem Domain!" 11:05 5. "I can't ask for Help! It shows that I don't know enough" 12:18 6. "Software Architecture is for the Experts!" 14:00 7. "Testing is someone else's job!" 15:20 8. "I would like to do a better job, but my boss won't let me!"

I've found that changing the question is a great way to find a solution that works. Never start by asking a customer what they are looking for, start with, could you describe the problem, or show me what problem you are running into. Not only will they willingly give you more information, everyone likes to complain, but you might be able to fix it in a way that gives them more value for less work. If not you can always follow up with, "and what do you envision the solution looking like." if you are talking to management, or "what can we do to fix it for you." if you are talking to a lower-level employee.

This video was humbling. I've been writing code professionally for 15 years and I'm guilty of some of these mistakes.

Oh, a development channel that doesn't make me cringe. I got goosebumps ... Keep up the great work

on the topic of Speed is all that matters" i always counter with "first you get good, then you get fast"

If you want to help the channel, share the video on the social networks. This man is giving you all the knowledge he has on a silver plate! Thank you very much for the video!

“Smart people ask questions, dumb people think they have all the answers.” Spot on! I was brought up on, and have successfully lived by the thesis “He knows the most who knows he knows nothing.” It’s where we all start and what enables us to learn.

With any career, it is important to be proactive. Don’t just sit there and only do just enough of what’s being told to do. Activate your mind, and always be curious at everything.

"There is a professional duty of care that we are all responsible for." --Couldn't agree more. Loved the "clean as you go" example.

This channel is underrated! Thanks for sharing that much of good content. Coding in itself is "easy", thinking, designing, debugging, launching a software is at an another level.

I've only watched a few of your videos, but I'm liking your content so far... In this video, for example, you have covered many topics that I have been preaching for the past decade, and It is heartening to finally find somebody else on the same wavelength. I have been working in the manufacturing business systems field for many years, and have had many of the experiences you described, and my real frustration is the fact that most organisations don't want to even acknowledge these issues, let alone change to a new way of thinking and working on I.T. projects. My company takes the much more modern approach to developing software - the main being that we do NOT think of ourselves as software developers - we are actually "Business Problem Solvers" - and computer systems are just the TOOL that we use to solve those problems. If you concentrate on actually solving the problem and improving the business, there are very different priorities. We find that if we stick to some simple principles (inspired by agile software development principles, which in turn is inspired by Lean manufacturing and Goldratt's ToC): 1. "Capabilities", not "Requirements" Concentrate on the overall "Capabilities" that the USERS need to solve the PROBLEMS - let the developers figure out the best way to deliver that capability, rather than insisting the business describe the requirement in real detail. i.e."I need to be able to take photos on a building site and automatically put them into a report template for our client" 2. Small batch sizes - develop and release capabilities in short quick chunks 3. Short feedback loops - get the developers talking to Users directly, release, test and refine a capability in as short a time as possible - preferably in hours, not days or weeks And in general, for solving business problems, the answer/system generally needs to the same simple things: 1. Make work visible 2. Be able to see any Business Operational problems quickly (and to "swarm the problem" as the famous saying goes) 3. Create communication "Protocols" between employees and teams - give the conversations common language, structure and methodology - reduces errors, confusion and waste. I think we sometimes forget that this whole industry used to be called "Information Technology" - as a society, we've concentrated so much on the Technology part, we forgotten that the actual reason that all this exists is to improve how we use and transmit INFORMATION - and this couldn't be more important than within a complex business. As software developers, we have the potential to MASSIVELY increase productivity in this country, if only manufacturing and business would adopt some of these simple approaches to using technology in their operations. They usually have a board of directors that includes representatives from HR, Health and Safety, Marketing, Sales, Manufacturing.... I have yet to meet a medium sized manufacturing business in this country that has a technology expert on their board - it's simply viewed as a "Service" like payroll or the canteen, whereas in this day and age - a real business strategy IS a technology strategy. My company has set out on a mission to change this situation by developing software that solves real business problems quickly and continuously, and finally get I.T. professionals "A Seat at the Table". James Hathaway - Technical Director at SigmaDX Ltd. Resources that insipired this post: Eli Goldratt - his entire Theory of Constraints master work. "The Phoenix Project" - by Gene Kim, Kevin Behr and George Spafford "A Seat at the Table" - Mark Schwartz "Black Box Thinking" - Matthew Syed (Better to fail fast and learn than to be paralysed by indecision) "Lean Startup" - by Eric Reis "Toyota Kata" - by Mike Rather

This is good stuff. The business will never get the requirements right alone. A good engineer will work with the business to define the problem and the potential solutions. Writing code, incrementally, allows us to test with the business the best solutions. We are not two teams. Keep up the good works, subscribed!

I didn't firmly grasp the concept of the finding solutions to the problem until my senior dev made me solve a problem without writing a single line of code. Basically using UML diagrams and logic to think through what was actually going on, it was a very useful exercise. Side note, I can't wait to get my copy of the continuous delivery book!

I used to work with computational physics (fluid dynamics), and a recurring problem I found in the community was that they were very focused on marginal improvements in speed or accuracy, but not as much on the physics - for example, always running against simple test cases or making unrealistic modelling assumptions. Also, not very much focus on UX or documentation and making their tools accessible to a wider audience.

I think actively evolving communication skills is vital. Its all about language, text, discussion and understanding the requirements and problems. A precise, meaningful and structured communication is so important.

Awesome content, thanks. IMHO, you can strike "junior" because some of these mistakes (especially the last) I can see long time professionals do as well (who might think of themselves as seniors)

Awesome, sharp and clearly spoken. This is what a software craftsman distinguishes from a developer.

14:12 _"If not, then you're dangerous, and need to take a step away from the keyboard."_ HAHAHA!

I started programming in 1970. I think these suggestions aren't just for beginners. This is the best you tube presentation on programming I have seen.

An Addition to the "ask for help" advice: Ask different people the same question, even if you think you understood it well after the first answer. You will most likely get to learn another point of view on that same topic and understand it even better. Same applies for online research, always have a look at different sources. Also dont worry about wasting peoples time, you might even do them an indirect favor! Explaining stuff is imo one of the best theory practices one can have, even if its just refreshing already familiar topics.

To extend the carpenter metaphor, it's common to see younger people arguing about what amounts to whether cutting the wood or fastening it together is more important, when any experienced professional knows the important thing - and the thing you'll spend the most time doing - is MEASURING the wood. In software development, people will argue incessantly about whether it's more important to design the code or to write the code, when the experienced professional knows that while both of those are critical... you'd better spend most of your time TESTING the code.

As a CS student, I found your points to be very enlightening and useful. Many thanks !!

Why are there only 73,000 subscribers as of today. This is the best youtube channel in IT, ever, period.

I have a Master of Science in Software Engineering and I honestly wish I could go back and replace my coursework with nothing but the videos on this channel since it honestly would have had a more powerful impact than the standard curriculum.

Watching this video feel so great that I can watch it again whenever I need to and it will always sound reasonable to me. Kudos Dave. 👍👏

Randomly found this channel. Found out that, on many points, I tend to think a lot like you, despite being in this business and in the same company for roughly 7 years, meaning that I lack a lot of experience. I love this and will most likely spread this among the colleagues, some of them definitely need to hear this =) Thank you for this.

This is kind of what is called "staying in the problem-space before going to the solution-space". Focus on the problem, the underlying assumptions, the whom and why, not the what or how. One of the biggest problems with us programmers is that we tend to jump directly to the solution-space. Some business person starts talking about a problem and 15 seconds later our brains have stopped listening to the problem and is instead filled with arrows, boxes, patterns and whatever technology we know. Five minutes later we don't even remember what the problem was, just that we get to write a bunch of code using nodejs, k8s, docker and NoSQL (because I don't have NoSQL on my resumé yet). What if the correct solution is to remove a feature, delete 10,000 lines of code and add a new step to an existing process/feature? Code is not an asset. Every line of code is a cost, a liability. It has to be built, tested, maintained, deployed, configured and operated. Programmers and code do not exist for the sake of their own existence even if we like to believe that we are. We are not getting paid to do our hobby, sitting in a corner with our headphones on, listening to "programmer focus synthwave mixes". Sorry.

This feels more like a critique of development teams and or the management rather than junior devs.

These are suprisingly good advices to any professionals, not just developers

The one I often see is following oft touted rules like don’t-repeat-yourself dogmatically, rather than pragmatically. The pros and cons of following any given rule should be evaluated when applied, because sometimes the extra complexity to the system isn’t worth the stated benefits

The man seems to be so competent and his speaking is so credible that I adore to listen to him even though I have nothing to do with IT 😂

All your points are 100 % spot on. Believing the client will provide a substantial and useable blue print for the new application is particularly bad. You have to take time to understand their business and take time to come up with the best solutions, which might differ significantly from what they think they need.

Hi! Love your content! Could I suggest you add time stamps to the description to add book marks on the KZfaq videos? For instance: 0:00 - intro, 1:48 - mistake 1: SW dev is all about coding, 3:47 - mistake 2: If only the business would get the requirements right etc... This is helpful so that viewers can jump to a specific point quickly in your video especially in a video with a list of items. I love the refactoring series. It's actually quite satisfying trying to make code cleaner and concise.

Thank you for this list. It's branded as for juniors but lots of seniors can learn from it as well, including myself.

Excellent, excellent way of saying what the value of developers is in context of "the business not getting the requirements right". It shifted my perspective on things, and I will be sending this video to friends of mine just for that segment.

I felt the need to give you a standing ovation for some of those points and the way you said them, especially the second one!

11:39 Beautifully stated, and a great piece of advice.

So many good points to think over for me as a junior dev. I alway find it difficult to ask questions, not because I don't know the questions to ask but mostly because to not be seen as annoying. Combining this to the point of taking the ownership, I will try not to feel intimidated for asking the questions.

God, I love your channel :) Seeing a seasoned veteran continue to work and engage in my industry gives me so much hope for my future

This was extremely reassuring for me as a senior dev.

About your last topic, addressing issues with management it is relatively a lot easier for a someone senior or someone with other options. People don't choose to not write tests or not to estimate right. These things could just so happen to be there. This is a lot more sensible topic, and I don't believe standing up works often, specially for Juniors and smaller companies. Of course this is often used as an excuse to not take ownership of a task, but lots of places do have a crappy work environment and won't let you do a better job indeed.

You just changed the foundation of my beliefs on requirements... Thanks! My job is a lot harder than I thought!

8:03 Please also mention that using many many libraries that came from nowhere does not mean "writing less code". Once a dependency gets added in any form, WE are responsible for maintaining it ir at least upgrading it in the future.

this video is a great insight, I'm guilty of writing before thinking and later having to refactor it.

This (all of this) is great advice. Not only for junior devs; this is what every day at the office should start with, or have these printed on a wall.

That point about writing code faster makes you better at software development. One of my biggest pet peeves with online training videos on KZfaq is the idea of, "this is how you can super quicky type fast" or "learn these shortcuts to be faster at coding" or the concept of a coding Ninja because your "so fast" and never touch your mouse! Mouse is bad for programmers, just keyboard. Hate it so much. There is nothing inherently wrong with any of it, but it fails to realize the true a nature of software development. I'm a senior developer for a large enterprise company and I would be lost without my scroll wheel :). This is the best advice I can give to a junior, slow down, breath. Think about the problem. Take your time. Understand what your goal is and get there with as little typing as possible.

I really dont know how until know I find this channel.... I have been looking at videos about programming since about a year now, trying to learn by myself and doing some minor projects, and until now I find this gem.... Thank you alot for all the info and all the information!! hope your channel gets as much as you which for it!

Love the chef analogy at 15:45

My working metode is. 1: make the test so it assert the expected outcome. 2: make the code solve the problem. 3: reveiw the code clean and refactore it. The first step forces you to understand the buiness/problem first. Second is to get it to work. 3ed when it works and the test parse then look at cleaning it up and look at performance

At the age of 57, I'm learning software development. I must concede that your videos give such a broad overview of software development, that it makes it always more interesting. Great !

I discovered this channel only a few weeks ago, and I am stunned by the quality of the content. In my opinion, all the videos are must watch for any engineer that cares about their work regardless of seniority. Thank you for making such great content available to everyone Dave.

This is the must for everyone starting a software engineering careers and repeat the watching for couples years to remind self..

just a note about knowing the problem domain, I do optimize, debug and improve lot of system without really knowing the domain at all, because I concentrate first on refactoring/cleaning the support material, libs etc. So many code are badly written, a lot of time optimization is ENORMOUS by reworking the inner algorithm (like changing a bubble sort to a quick sort improvement) one of my last dramatic change was rewritting a SQL query that was written by an Oracle DBA, with all kind of obscure command and attribute proprietary to Oracle, I just clean it back to the originale intents, write the proper query, with trigger and precalculated value so the 12 hours report dropped down to 15min ... without any specialized oracle commands, my query work on any SGBD with minimal syntax adjustment! Combine this to the KISS principle, and optimization and easy maintenance is usually the results. But I guess you need to be a bit more experienced before attempting that, too many employer got burn by eager junior to 'rewrite stuff' .. but if we didn't reinvent the wheel, we'd still be on wood wheel... With experience you start 'smelling' the poor code that would gain a lot by refactoring/redesigning...

As a new developer when minor issue fixes and support work is assigned - instead of jumping into solving the problem. My recommendation is to take it slow - Understand the system - Digest the workflows and Domain knowledge around it - Then try to go for a fix. This would definitely take more than expected time for solving the problem - However the time spent on understand the system and data flow around it is worth building knowledge over the long run.

8:00 I love that you would say that, as when I think fast and am awake I type fast and make big changes on the fly all working, but when my brain is chilling I'm gonna have a really long time typing one word, like a cold engine unable to warm up.

8:00 about the fast typing: personally, I gain greater insight into the code by simply attempting a solution and then improving on it, rather than by, say, pseudocoding and trying to get at the answer by non-coding means. It's sometimes hard to oversee the nature of the problem without actually looking at some code that forms part of the solution, even if it's a suboptimal solution. I agree with most of what you say here but for me, working fast and typing fast are integral to my ability to focus and concentrate

The last one is sometimes true though. One project I worked on I told them it's a 12 month project. They gave us 4 months and pocket change. Every meeting when they asked about progress I told them, we will not meet the deadline, we need at least 6 months extra runway. Naturally they would argue about the schedule not aligning with business interests. I told them this is a foundational system and surely that is more important than whether the release window is ideal - if so concerned, then push release back to next year and we can use the additional time to improve the system further... Never budging...

Excellent advice. Gets better as it goes on.

I worked at a place where the clients often did not know what they wanted and when they thought they knew what they wanted it was sometimes based on false notions. I had a talent for explaining things in a simple manner that non-technical folk could follow and find out what they really needed even when they wanted something that made no sense. I am not sure if I should mention the last part of that to potential employers though. They may not like the idea of employees second guessing their clients' wishes.

I am a new dev in my first year and this is the best video! I've seen many of these mistakes made by myself and others.

The issue with number 2 is when I notice an issue and let business know about the issue they come back at me with you figure it out which is great giving me all creative freedom to mess someone’s financial life up. What is exactly the business job? Isn’t it to come up with requirements?

Great video, such important topics that are not discussed enough. Thank you!

"the coding is easy. if the coding is hard, that is nearly always because you don't understand enough about the problem." ABS. LOVE THAT!

Great video, thank you! I'm two months into my first software engineering role and luckily haven't fallen into most of these traps... a few might be borderline though hah

"We shouldn't be asking other people permission to do a decent job." Nice one!, I'll remember that forever.

I have one I learned early on: “It isn’t my job to explain or teach.” Is this mad? You bet it is. Eventually I will have to teach the team why I developed the way I did. I may even be assigned to write the draft of the user’s manual and other documentation. So it helps with my writing and editing skills. Here’s another systemic view. I keep this mind when I’m developing. It also helps me become a little better organized as I go along.

I just started coding a year ago and somehow landed a job in an awesome company and I felt so soo off in the beginning, because I wasn’t fast enough, I still don’t know what they are talking about in technical meetings and I made a lot of mistakes. The thing is, nothing of that mattered. I asked people frequently for their opinion on my ideas of problem solving in order to improve. And funny enough, my senior colleagues are just the same. I find it funny how when we pair program my boss is always like: „what… I don’t understand what it does here“ - same, man!

Couldn't agree more with all of these (which - imo - apply to other roles as well to a large degree) "I can't ask for Help! It shows that I don't know enough" I find especially interesting. In my experience it happens so often that if one person doesn't know the answer, there are other people who also don't. Or a team thought they did, thought they were aligned, while they weren't....

Than you for sharing your invaluable knowledge and experience!

Love this. As somebody that has been doing this 25+ years, this is pure gold.

Wow! So much value in a 20 min video! I would need to re watch it again and again to truly understand the ideas completely. Thanks a lot for sharing your experience!

Very pertinent Especially, the last one

The part about "If only the business could get the requirements right," being wrong is something I learned early on in doing freelance 3D animation. It was my job to know more about animation than them. If they recommended I make something that I knew would look bad, make text hard to read, not convey the correct information, etc. it was _my job_ to clearly (and politely) convey why it wouldn't turn out how they think it would, and come up with a better solution that would reach their desired outcome. Examples: Client says it's too dark and tells me to make the lights brighter; I intuit that they're saying this because the text is hard to read and instead make the background darker to make the text stand out; problem solved. Client says they want the camera to move faster because they don't want long shots of nothing; I realize this is probably because it's early on in the project and we haven't added the text the viewer will need to read yet; I add in the text without adjusting camera speed and the client thanks me for speeding up that shot. The client always gets the final say, but it's your job as the animator/programmer to translate what they _say_ into what they _want_

I do take exception to the final point. In most organizations, whenever there are problems, management really is at the root of it, about five times out of six. Most juniors are raring to do more than code; they want to develop a quality product whose usefulness to the user is maximized, and they want to be involved in the architecture as well as the implementation. It's managers who say, "Shut up and code." It's managers who treat questions as a sign of weakness. It's managers who press for code done quickly instead of code done well. It's managers who decide to ship code that doesn't work.

I love how he just dumps the sponsors at the beginning of the video without any further explanation of what each of them do.

Love your videos, titles sound like the titles from thousands of other clickbiat videos, but you actually give deep thoughtful and instructional answers/solutions!

There's another reason you can really help the business understand their problems: you can give them the computer's perspective. It's easy for people to gloss over situations that rarely happen but, when you're coding, those issues are far easier to see. "If such & such then DoThis() else... ummm.... uhoh."

no idea how i landed here... but old timer here is right. Here is another old-timer (me) confirming what this man is saying. Figuring out what the client wants in a quick fashion and doing that right... well, when you are able to do that you are already a senior. Tip, think more about your intake process.

Recently discovered your channel and I'm very impressed with the advice. I'm a hobbyist dev looking to go pro as a full stack web dev. I never really used to write tests but have recently tried out a basic tdd approach and it was really interesting and helped me think about the problems I was trying to solve.

I love the saying I heard on J.Peterson/M.Dillahunty debate. "being wrong always feels as being right"

I want to reflect on the "I want to do a better job but my boss won't let me" point. I was and still accused with high demand for well organized, easily readable code, and that I am refactoring too much. I thought about it long, and found out that I demand high quality, and high quality code is pretty, it is a joy to work on such code. So anybody tells you do not refactor so much, you tell them I just aim for high quality.

4:23 I don't fully agree about the business. I wouldn't say, it's the job of the programmer or the business alone, but the programmer has to find out by talking to the customers while making suggestions and clarifying, what would be possible. Else half of the code will have to be rewritten because the customer doesn't like it.

Invaluable advice. I did nearly all of those mistakes in the beginning :D

While I trust your expertise in many things, I cannot agree in the part about "I could do a better job, but my boss won't let me!". Obviously, you are talking from your perspective, from your experience. And while, in some cases, I had a similar experience as you... in some other cases, it was the opposite. In one company, the software created, was for the company itself, so ... they wanted quality code, of course. That meant, better code, less time invested in the long run, and less bugs along the way. BUT, and this is a huge one, in another company, they wanted us to patch things up quickly for the client, with less quality code. To the point that I was able to see an issue that I had worked on (I had the right solution, but could take about 3-4h to code/test/etc) in about 1h30m, by patching it up fast (the system was a bit of a nightmare, no repos, dealing with cache systems, publishing directly to production, ... you name it!), being fixed again, and again by EVERY SINGLE MEMBER of the dev department. Total estimated time for all the patches? about 9h of work. But ... what happened, well ... every single hour was billed to the client, so ... "it was good for business". The other devs and me, we did not paid attention to what management was telling us, in regard of the bad quality code (we did paid attention to anything else, obviously), and we started doing high quality code. And we were able to 'good-code' us out of a job. YES, we were all fired when all the sites and services were up to spec, and jobs taken back to India (were they were originally taken from). Believe it or not, the spaghetti code on those sites was HORRENDOUS! To the point of ... low score on google speed pages, long and difficult to update sites, redundant code, etc. To put it mildly, there was a horrifying "dynamic" menu made with about 100 lines of code, where the dynamic part didn't work, so they left it there, and hardcoded every part of it. It took me a couple of hours, to remove all that, and in 15 lines of code, the menu would scan the objects tree(an object could be a whole page, a section, or a button, etc.), filtering the pages, and checking the value of the "menu" property, and if it wasn't disabled, it would add the object to the top menu, or the footer, or both. It was faster, cleaner than the original, and when I let marketing know that they could use the menu dropdown to set up their menus, they replied ... "But ... that had never worked before!" ... well, now it works! So that was what we were dealing with. PS: Our bosses also got sacked. Departement boss, team leader, etc. It was cheaper to move jobs back, after we fixed all the sites. 🤷‍♂

Great channel and great video. The beauty is that the narrator is actually talking in terms of principles - much of what he describes can actually be applied across the wider business.

I’m so glad I found this video!

Thanks for a great talk!

He is absolutely correct about these issues. Someone needs to the employers this as from most of my experience employers are the ones that push a lot of these problems. You can see these examples in job descriptions and if you ever worked in the industry for awhile you would notice they tell you today but expected it to be done last month.

Have only one objection. These are not limited to junior devs. Realizing that I am in or about to fall in one of these traps is the times in my career that feel like I am an expert for a short while. Never relax on these issues or I might fall into it again. Great video👍 talking from 20+ experience.

This video is awesome. But I think it has one big flaw: the title says "junior" which means many people won't be bothered watching it because they have x years of experience. This should be called "Avoid the common mistakes Software Developers keep making" or something like that.

Recently designed and developed a planning application. After a year working on it, some of our junior developers did not understand anything about what the application was planning , when they actually did know that it was a planning application at all. I wish they had watched your videos ....

So much knowledge, thank you

Thank you for making this video. I'm making a career change into web development and these are helpful points. Fortunately, I've always been a very curious person and love learning things and asking questions. I'm hoping that will help me here. Have a good one!

Finally common sense in software development. Kudos!

"If only the business would get the requirements right." Long story short. Created a Time and billing system, front end web user time entry and back end billing. This was for private special ed teaching to public and private schools. Time is billed in complex ways. Program completed and working. Then we are told that they can also be paid if the appointment is not made. SO we have a whole billing systems triggered on time entry but now we have to also bill certain contracts if no time. Sort of busts apart our whole foundation. Plus a bunch of other stuff they never told us. Now it's our fault for all the extra time and the bugs that were now introduced making changes to a live system.

love your videos man. keep them coming please!

The objection against typing/practical speed is a commonplace one, but it's false. Problem solving is a wide realm, and part of it is exploration, experimentation and trial-and-error.

Hi Dave, I'd like to call myself an "artesano del siglo veinte y uno". Our work has must to do with iteration, trial and error, rather than something that ressembles some ford line of facturing. Big cheerio from Chile.

Great video! Thank you so much. Hope that you continue making videos!