Avoid These Common Mistakes Junior Developers Make!
ฝัง
- เผยแพร่เมื่อ 13 มิ.ย. 2024
- What are the common software mistakes that junior developers make, and what to avoid as a junior developer? Advice for software engineering students and people starting out in their career from an expert.
In this episode, Dave Farley describes 8 common mistakes that junior developers often make and offers his advice on how to avoid them. Whatever your approach to software engineering and software development, whether you are practising Continuous Delivery, DevOps or something else, we think that you may find some helpful ideas in this video.
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Kindle ➡️ amzn.to/3DwdwT3
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
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
___________________________________________________
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.
➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
-------------------------------------------------------------------------------------
REFERENCES & ATTRIBUTIONS
Apple Lisa Pic Curtosy of Wikipedia (CC License) ➡️ en.wikipedia.org/wiki/Apple_L...
Apple Newton Pic Curtosy of Wikipedia (CC License) ➡️ en.wikipedia.org/wiki/Apple_N... - วิทยาศาสตร์และเทคโนโลยี
Do you have any other tips for developers at the start of their career? DROP THEM IN THE COMMENTS BELOW! 👇
Don't try to "beat" anyone in speed etc. and try to focus on collaboration instead, or you will generate resentment from the person you "beat", you really don't want.
Don't be crazy possessive about your code. Your "perfect" code could be changed by someone else and getting all pissed off about it is incredibly annoying to everyone else.
Be very thoughtful and caring when pointing out someone else's mistakes. Point out that you have also made the same mistakes in the past.
Proposing innovations and improvements could land you into conflict with the person who was responsible for the code or the process you suggested could be improved, because he or she didn't think about it first. Make sure you compliment that person's efforts first.
Growing from novice to a better developer is not about reading a lot of beginners' books, watching a lot of tutorials or going to a lot of courses; it's a slow process that imply **doing*: Make a lot of programs, say, *solve** a lot of problems, and **make** a lot of mistakes. It could seem overwhelming at first, but it is an exponential grow. Not only solve the problems you have **ordered** to solve: Find similar, simpler problems and solve them. The insight so obtained is the oil that will make your solving machine go smoother and increasingly powerful.
I have a saying in my shop: "The user doesn't know what they want until you show them what they asked for!" This is an essential part of the requirements gathering process. By building an early/quick prototype version of a system that represents your understanding of the user's stated needs, you establish a 'common ground' or 'context' from which to grow the real understanding of the requirements. And as a bonus, the user feels more engaged in the process as well.
I want to reinforce: if you say you are done with the task, but when asked if you tested, your answer is no, then you are not done.
You are not even half done. You barely started.
Don't be afraid to ask colleagues for help.
More often than not, someone you work with knows as much or more than you do, and they are as or more worthy a resource as a bookshelf, or a Google reference. Even senior-level people ask questions and yes, sometimes they ask dumb ones. Outside forces can affect someone's thinking: C19 human malware, family matters, and so on. And don't just ask for coding help, all the topics are valid: design, user desire, business rules, etc. Ask for help when you need it. Ask for context when you need it. I would suggest taking time to research the problem you need help with first. It does get embarrassing to ask a question only to answer it yourself the moment you hit send--but senior people have been through that. Still, it happens.
I'm not going to deep dive on the, "what if I ask too many questions, will I get fired?" route. The truth is you'll always be evaluated. Generally when you're hired, the company has a good idea of what you're capable of--also why most companies have a 3 month probation. Learning the company's software for example will likely be an initial role, and sometimes asking questions is expected, and not asking questions might be the wrong thing to do.
*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!"
Thank you for time saving🙏
Before watching the video I thought those were the solutions, a little harsh but still, not the problems
This is a bit of a weird video to timestamp, just watch the whole thing lol.
@@imadetheuniverse4fun it's more for review purpose tbh
Thank you sir. you are doing gods work.
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.
better and better on a daily base, lifelong apprentice ! ;)=)
Kind of similar here, writing software for some years, and unfortunately in an environment that is not quite state of the art concerning tools and methods. So there is a lot to improve (at least superiors are open for these).
Continuous Improvement, both on an individual and on the company's side...
WE All Are Hey!
You realise you've grown up when you realise you made those mistakes, and you try not to make them again, knowing the consequences. Eventually, all of those mistakes were made, and you can finally enter adulthood.
So that's where all those "Junior dev with 15+ years of experience" are coming from? 🤣
Just kidding of course, don't take it personally ;p
Oh, a development channel that doesn't make me cringe. I got goosebumps ... Keep up the great work
He didn't even ask us to "smash that like button"!
Yeah he earned a sub just because I have struggled with getting my foot in the door of a development job and I feel like his wisdom will be invaluable in building if nothing else my self confidence to make more so I can flesh out a better portfolio.
* cough * The Tech Lead * cough *
@@J90JAM that guy is trash
@@techtutorvideos exactly.
on the topic of Speed is all that matters" i always counter with "first you get good, then you get fast"
From the US Navy Seals: "Slow is smooth. Smooth is fast."
Going fast in the wrong direction will crash you into a wall. Try to know where you are going and do not paint yourself into a corner.
“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.
"There is a professional duty of care that we are all responsible for." --Couldn't agree more. Loved the "clean as you go" example.
Thanks
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!
Thank you 😊
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.
Yes, it is obvious that new people are looking for guidance, but at some point we all have to take ownership of our own work.
Being proactive is only possible when the culture is right, I'm currently working at a company where it is absolutely not appreciated. I've been yelled at multiple times for simply notifying the team about bugs.
@@unrealcyberfly , my advice would be to proactively try to fix the bug. Then, present to your boss the fix. In my experience, bosses don’t like complainers, just doers. It will put you in a great advantage as a dependable member of the team.
@Peter Tran In this case the bug comes from a colleague's output. I've cleaned up their mess before, no more! Colleague is the boss' sweetheart and hides "behind a lack of knowledge". --- I just needed a place to rant, thanks for listing.
@@unrealcyberfly Goodness, that's the worst
14:12 _"If not, then you're dangerous, and need to take a step away from the keyboard."_ HAHAHA!
😉
@@ContinuousDelivery Made me subscribe :D
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.
Sadly, they keep stacking up the expected requirements for a job too. I think it would be better if the bosses would hire programmers from a few different experience levels and then a lesser programmer could actually get experience and the higher level programmers could have someone to take care of some of the grunt work.
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'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 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.
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 like drawing pictures to visualise problems, not necessarily UML, but sometimes. I hope you enjoy the book 😎
"We shouldn't be asking other people permission to do a decent job." Nice one!, I'll remember that forever.
Awesome, sharp and clearly spoken. This is what a software craftsman distinguishes from a developer.
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)
Yes, sadly true.
Being "Senior" or "Junior" has little to do with how long you have been doing the job. Perspective is much, much more important.
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.
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.
Yes, I should have extended the metaphor 👍😁
This feels more like a critique of development teams and or the management rather than junior devs.
yeah most of this is just bad habits you get from working with bad people
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!
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.
💯😎
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.
haha so true ;-)
I hope you feel you got your money's worth from school. It's lots of sacrifice to get a masters. I'm going through mine now. I would probably feel so jaded if I thought it was a waste.
@@kb3khs You don't go to college to learn new things; information is freely available to anyone and a teacher is only there for support, not to gatekeep knowledge. You go to school for a piece of paper that vouches for your critical thinking skills and lets an algorithm that processes resumes sort yours into the "review" pile instead of the "reject" pile.
Love the chef analogy at 15:45
Love your videos, titles sound like the titles from thousands of other clickbiat videos, but you actually give deep thoughtful and instructional answers/solutions!
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. 👍👏
Glad you enjoyed it!
Great video, such important topics that are not discussed enough. Thank you!
Great video! Thank you so much. Hope that you continue making videos!
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!
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.
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.
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 😂
Dafuq ? lol I kinda like people who arent in IT taking an interest in what we do.
CHEERS MATE !
These are suprisingly good advices to any professionals, not just developers
Yea, I'm a test automation engineer and a lot of things mentioned in this vid are applicable to software testing/test automation. I'm gonna share this with my co-workers :)
Excellent advice. Gets better as it goes on.
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.
True, different angles will give you better overall understanding of an issue, since you're covering more ground.
Than you for sharing your invaluable knowledge and experience!
Your channel has helped me greatly! Thank you for sharing your knowledge!
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!
Great information! Thank you so much for sharing.
This has been extremely helpful, thank you for this.
Thank you for this list. It's branded as for juniors but lots of seniors can learn from it as well, including myself.
Why are there only 73,000 subscribers as of today. This is the best youtube channel in IT, ever, period.
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!
Thank you! I hope you found it thought-provoking!
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.
Thanks for the feedback - good to know the video has made a difference!
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.
Thank You! Glad you enjoyed it!
such a good speaker - love this!
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.
Thanks for a great talk!
11:39
Beautifully stated, and a great piece of advice.
So much knowledge, thank you
As a CS student, I found your points to be very enlightening and useful. Many thanks !!
Sigh, true 😉
Glad it was helpful!
@Xiaoran Meng Just to add to what you said: The number of years someone has been a developer may be an indicator, but is certainly not a true measure of seniority. I have seen people who had worked 25+ years as developers, and still could not design anything non-trivial by themselves. Conversely, others needed less than a year out of university to demonstrate true talent. Remember: Having done the same thing for 30 years without constant learning, is not the same as having 30 years of experience. Instead it means "I have learned during the first five years and then stopped progressing".
CS stud here too. Thanks for the vid!
Thanks for this insightful guidance 👍
love your videos man. keep them coming please!
Thanks! Will do!
Very pertinent
Especially, the last one
Invaluable advice. I did nearly all of those mistakes in the beginning :D
this video is a great insight, I'm guilty of writing before thinking and later having to refactor it.
I love this kind of videos, please never stop it from coming
This is an outstanding video even by your already high standards. I'm glad I've got something to link junior people to when I hear this stuff.
Brilliant advice. Thanks!
Glad it was helpful!
First video I've seen from CD and subscribed at the end. I'm brand new to software dev but not new to the cybersecurity industry or general life/work principles and this video was spot on. 👌
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.
What's a basic TDD approach
Excelent content. Thank you!
Thank you so much!
You just changed the foundation of my beliefs on requirements... Thanks! My job is a lot harder than I thought!
Yes, it is, but more fun as a result 😁😎
I’m so glad I found this video!
This was extremely reassuring for me as a senior dev.
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.
Thank you for your wisdom. What a treat. It's amazing how much of what you are saying applies to life in general.
Glad it was helpful!
Hi! Love your content! Could I suggest you add time stamps to the description to add book marks on the TH-cam 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.
0:00 - Intro
1:40 - SW Dev is all about coding
3:47 - If only the business would get the requirements right
7:08 - Speed is all that matters
9:21 - My job is to code not understand the problem domain
11:03 - I can't ask for help, it shows I don't know enough
12:17 - Software architecture is for experts
13:58 - Testing is someone else's job
15:18 - I would do a better job but my boss won't let me
16:42 - summary
Thanks for the suggestion
@@ContinuousDelivery no worries! Please see the above message for the complete time-stamps for this video. I believe you can edit the description after posting and it will update the timeline 👌
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.
Thanks 😎
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.
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
Agreed, to every DRY sycophant, I offer AHA. The rules are there to handle things generally, doesn't mean they cover every case. While I'm ranting, less lines != better. I hate it when people play code golf with production code that's maintained by a team. Write for the team. Final rule, and this is one I find to almost always be true, premature optimization is a quick path to hell.
@@TheMrVogue What's AHA?
Some great insight there. Especially #2.
Love this. As somebody that has been doing this 25+ years, this is pure gold.
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.
Fantastic advice.. thank you
This is Gold, thank you :)
Thank you
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
Thanks 😁
Finally common sense in software development. Kudos!
Appreciate your insights!
Thanks
Thank you!
I really love the way, how this valuable information is presented. I believe I can learn a lot from this channel.
Thanks
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.
If you don't ask questions to get a better idea of what needs to be done, you will definitely feel intimidated later when things go wrong
Eeeeh this can be broadly applied outside of software development. Great stuff
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
Thanks for the video =)
I must listen to this, tons of knowledges and wisdoms
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
😇😉
Thanks!
A very good 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.
I love how he just dumps the sponsors at the beginning of the video without any further explanation of what each of them do.
As a developer, you know you're supposed to look up what they do on your own. 😄🤣
Dont let anyone know you don't know what they are hushhhhhhh its a secret.
🔔 SHAME! SHAME ! SHAME ! 🔔
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...
I've been a developer for 3 years and this is still somewhat insightful. Thanks sir 🙏
that's Amazing video!
This is the must for everyone starting a software engineering careers and repeat the watching for couples years to remind self..
I tend to tell new developers starting at our company the following: "You are not getting paid to write code. Your employer doesn't care for code and nobody of us will say you've done a great job just because you've written a lot of code. Your task is to find a way to make things happen with as little code as possible. That's because less code is easier to read, less code is easier to maintain, less code is less error prone. And quite often less code requires less system resources and will run faster as it means less work the CPU has to perform. That said, less code is not always the best solution. BubbleSort has less code than QuickSort, yet you don't want to sort large data sets with BubbleSort. So writing more code than the bare minimum is okay, just as using more system resources than the bare minimum is okay, that is, as long as you can justify doing it."
you can just say write optimized code.