What Are Some Major Mistakes Developers Make in Their Career?
Вставка
- Опубліковано 3 кві 2024
- In this episode, I will cover the seven major mistakes developer make that waste their time and slow down their career. This episode will answer questions like "What are some major mistakes developers make in their careers?", "What are some things that slow down the progress of a developer?", and more.
Website: www.iamtimcorey.com/
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/
1: You just learn the latest things (0:56)
2: You just learn what is needed at your current job (6:20)
3: Not practicing (8:53)
4: Learning design patterns before learning how to build an application (12:07)
5: Dunning-Kruger effect - Believing you know more than you actually do (15:52)
6: Not honestly evaluating your own work (24:18)
7: Focusing on scalability instead of simplicity (27:20)
Thank you
38 minute video without timestamps, seriously CBA... Thanks for this!!
Thanks bro
You're spot on Tim. I've made three of these mistakes. My first job out of college was all legacy technology nobody was using. Joys of insurance companies who move slower than an iceberg. It was really difficult to find another job. While I was learning on my own, I had no proof I knew anything since I had zero "professional experience." If I had a portfolio it may have been easier. While I had applications I created, they were all proprietary code for a small business I started and I wasn't willing to share code.
Yep, that's a fairly common story. I'm glad you were able to move past it. Thanks for sharing.
1. Not concentrating on one technology.
2. Ignoring continuously and for a long time the releases in a given technology.
3. Keep having a low code quality (no comments, no design pattern, no inheritance, no tests, no migration)
Thanks for sharing!
Master, this video helped me clarify many doubts I had. Your advice is worth its weight in gold. Just recently, I was discussing these topics with a friend. Thank you very much!
You are welcome.
Thankfully I learned how to build applications before design patterns. And this whole time, I thought I was supposed to learn patterns first. Since I specialize in programming against Active Directory in C#, I look back on my legacy code that didn't use a design pattern and 15 years of experience helps me see what I did that could have been done with more efficiency making less calls to a domain controller.
Thanks for sharing!
Great episode dear Tim. I almost made three of these mistakes. Because of your episodes, you cleared two of my mistakes. Thank you, dear Tim, keep it up.
I am glad it was helpful.
Quite the opposite to the mistake that you mentioned (Dunning-Kruger)
"Imposter Syndrome" totally blocked me for long time.
Yep, that can be a tough one. I did a whole video just on the topic.
As usual great content Tim. Can you make video on clean architecture if possible
Thanks for the suggestion! In order for me to track it and for others to be able to vote on it, please add it to suggestions.iamtimcorey.com
Thanks for another great episode!
These are my mistakes. I will work on them and try to correct them.
1. Learning only what I need for current job.
2. Not practising enough of what I have learnt
3. Not honestly evaluating my work regularly
Thanks for sharing!
Strange actually as I self-reflect on what you're saying I see a lot of those problems in myself I might have to think about things a bit thank you Tim
You are welcome. I'm glad it was helpful.
This is quite informative. I didnt know design patterns come at a cost.
I am glad it was helpful.
great talk!
Thanks!
Excellent vid , Tim. Certainly guilty of a few at various times. Primarily either going to hard on building and extra learning and burning out to where I do nothing but my job. Would be a better if I broke the projects down more. Focused on the deeper details of each piece I’m leaning then apply it. Trying to take the whole cake at once does not work.
As always, thank you for your guidance.
Thanks for sharing!
great advice!
Thank You!
Microservices, I've hear this mentioned on small projects so often. It's a distraction. Our app was hugh and we just ran more threads to handle it. You an always make the front end server bigger. In fact, you can just use your "monolith" and run it in a different namespace and viola, you have a microservice. I can think of one case we had which was image delivery, in that case we just created a small app and used that to deliver that info on demand (CDN was not an option). In general though, I'd avoid microservices.
That's typically the right approach.
AI will never be able to code what needs to be interpreted from idiot administrators demanding application requirements.
I’d like 5 green lines, 3 drawn in red ink
That is one of the major skills of developers - taking poor requirements and turning them into a good application.
Tim's choosing violence today. What's with the personal attacks! Appreciate you, Tim.
😂 Sorry. I attacked myself more than anyone else.
How do I achieve the simplicity?
What are the roles or the steps I have to follow?
Lots and lots of practice. Keep evaluating your code and seeing what you can do to make it simpler. Not less lines of code, though. Simpler means easier to read and maintain.
@@IAmTimCorey Thank you so much for the answer.
1. Not practicing enough.
2. You just learn what is needed at your current job. I already kind of regret that I didn't keep going with other technologies. (in sudden layoff it will be a thought time for the junior to find a new WPF job)
3. Believing that I am better than I actually am.
Recently I was patient about to learn Rust programming language to have a low level language at my tool belt. To be honest there are a tone to learn within C#
Thanks for sharing!
"Only" Nr. 2 (current job focus) in my case I believe, but that one really Big Time!
Now that you've identified it, time to work on squashing it.
@@IAmTimCorey Sure, I'm on it, it's just a matter of a couple of years to catch up...
This is gold 🥇
Thanks!
major one for me was STAYING LONGER than 2 years in my previous employments! Should have job hopped to gain more experience and exposure.
There's a balance there, though. Employers don't love a resume with lots of short jobs on it. The reason being that they don't want to hire someone, get them trained up, and then see them leave in a year or two. So moving jobs to get a raise and different experience is a valid technique. However, doing it multiple times in a row is almost always a mistake.
Awesome, my impostor syndrome level just tripled.
Why? If you know what mistakes to avoid, you will be better able to make the wise choices. That will lead to better outcomes.
In few years from now, none of these will be relevant for devs to learn and keep up with technology as more and more AI will take over dev jobs. Feel bad for students in college going for computer science degree today.
They'd better get learning AI skills then. We all had to adapt.
I disagree with you. I believe AI is a tool and will continue to be a powerful asset for programmers
@@Lightw81 Just the other day dev from another team was showing us how they're planning on using copilot to rewrite code. He was chatting with copilot and saying I want you to refactor the highlighted code and it was doing it. So, as AI advances more and more, you'll have need some understanding of programming and AI will do it for you.
Nah. These will be fairly universal for decades to come. Even if the "AI revolution" comes about and "junior" developers are replaced by AIs (which won't be what actually happens, by the way). Did you notice that Microsoft called their AI "Copilot"? There is a reason for that, and it isn't just to make it sound good. AI will not replace humans. It will always take a driver. It is an incredible tool for helping you create things quickly. But that's not the same as being a tool that creates things on its own.
So, if it is always going to require a human driver (the pilot), who are companies going to hire to do the "piloting"? In the case of development, they will be hiring software developers. Why? Because AI doesn't think on its own. It doesn't understand how to validate what it tells you. It is wrong sometimes. It introduces subtle bugs. It doesn't understand the full context. It doesn't actually create. I know it looks like it does, but it isn't actually creating anything. It is mashing pre-existing things together and hoping that the result is what you were looking for.
What that means is that the person driving the AI needs to know how to validate the responses, how to refine the query to the AI, and more. That means a skilled developer. Sure, that developer will be more efficient with AI, which technically means a company could get by with less developers, but it also means that more companies can take on development work because they can afford it. That means in the end there will probably be more developer jobs, not less. It will just be different than before. And those developers will still be subject to this list of 7 mistakes developers make in their careers.
@@TISINLI2 There's already many jobs in Software Automation, worst case scenario you'll still need Software Devs to operate that. At work we're working closely with Microsoft around Co-Pilot and much of these tools have many limitations and problems. AI can only do so much - video game engines will be a good example of that.