@damny0utoobe
I'm a senior dev and a scrum certified product owner and I can honestly say that many organizations abuse the whole velocity concept to prematurely force developers to "finish" their stories and tasks. They have taken something that developers love (development) and turned it into a sweat shop. So please, respect your developers and stop pushing your team to its absolute breaking point just to meet some arbitrary velocity.
@thegreatclarifying6339
"If you don't have time to do it right the first time, what makes you think you'll have time to redo it." I had that quote on my whiteboard for years.
@dpuplava
20+ years of development experience here - I agree with all these points. To reiterate an overarching theme, as a professional developer, do the professional thing and take ownership for your software. Notice the keyword being "software" and not "code" because software is more than just code - it's the documentation, communication, refactoring and timely delivery of that code.
@tjmcode
I've work inside a very large manufacturer, and when I present all of these principles--and try to enforce them on new projects from day one--I'm very surprised by the reactions from other team members. This video assured me that I'm not crazy and I've been doing it correctly for decades... Thank You.
@stevejohnston2137
Jamie, This was great advice as usual. I started programming 50 years ago back in 1972 before Structured Programming had been invented in 1973. At the time, it was thought that writing computer code with the fewest lines of code was the mark of a truly gifted programmer. Remember, at the time, many programs were written to be only run one time by the person who wrote the code! This was very much like the Baroque period of music (1600 - 1750) in which Bach lived. So, at the time, programmers were like Baroque composers such as Bach who were commissioned by the King to write a piece of music that was only intended to be played one time at a particular regal function by a single orchestra and then discarded. So there was very little effort devoted to preserving Baroque musical compositions, and that is why we have very little Baroque musical code left for us to enjoy beyond the works of Bach and a few other composers. Only later in the 1970s did I run across "canned" programs that were meant to be run more than once using input data punched on a deck of cards. That's when I learned that "truly gifted" programmers did not write code in the fewest number of lines of code. Truly gifted programmers wrote code that others could understand and work with 10 years later! Regards, Steve Johnston
@justgame5508
I like the quote “There’s nothing more permanent than a temporary solution” It applies well to the leaving code j finished scenario
@midoevil7
I think some of points that distinguish a senior programmers for me : - They know WHY: when you ask a senior why this was done, they will usually have a logical answer, even if you don't agree with it, but their point will be consistent and reasonable, and usually will offer another point of view that wasn't obvious. Juniors and "Pseudo seniors" will usually give excuses, can't provide a consistent answer, or pretty much rely on their authority to push their view. - They have insight: Good seniors can make use of their experiences to predict the different outcomes of different decisions, in a way, they can make mental simulation, and so, they can save their team lots of time and effort by guiding them to avoid future problems, or at least set the project in a way flexible enough to keep going without hitting a deadend. - They are good at handling and understanding business-side: wither it is based on trust or good arguments, good seniors usually know how to deliver their points to product-owners, product-managers, or business users. They may predict the business side concerns before feedbacks, or - They are good at making trade-offs: this is based on the last points, with enough experience insight and negotiation skills, good seniors and tech-leads can make flexible trade-offs to offer the business as much value as possible. - They are NOT perfectionists: Good seniors that "Good enough" is always better than "Expensive Perfection"
@yar3333
I really love that you wrote the summary text in the description. I've read the essential parts much quicker than it would take me to watch the video. You are a senior YouTuber for me, many thanks!
@nl8345
I've been a freelance graphic designer for almost a decade. SO much of this is exactly on point. Levels of communication, consistency, and clarity are what really separate the individuals who are a joy to work with to those who may be talented, but I would not want to work with again.
@JonnyBasement
I’m a software development manager and former front-end web developer since 2003, great video and it’s interesting to see someone give their perspective on what it means to be a senior. I’ve been a part of many projects, both brand new development and inherited code bases at several different companies in my career. What I look for when hiring senior developers is a sense that they have some wisdom and experience in what they do, regardless of the language they code in, you can see from interviewing them that they’ve encountered many different development scenarios in their career and they think deeply about what they do. They aren’t too hard-headed, or proud, or set in their ways that they think they have learned everything they need to know, and everyone needs to do things their way because they know best. Humility is vitally important for cultural reasons in a company and also for the success of projects to be able to see obvious pitfalls and roadblocks during development. Over-engineering can be the death of new projects and features. I want my developers thinking about solving the problem as simply as possible from the get-go and only introducing further complexity when it is required. I’ve even done it myself where I’ve tried to implement a new tech stack that I wanted to use, only to get into it and find out it’s adding way too much time and complexity. Usually because the documentation and best practices says that I require a whole lot of scaffolding for my application. This is bad for business. Take best practices into context but still try to solve simple problems with simple solutions. Dependencies create complexity. The more dependency you introduce in a code base, the more chances you will create bugs and add fragility to the project. If you reduce dependencies you will likely reduce the bugs in your software. Also, code so that others can easily understand it and debug it. Even if that means a few extra lines of code. You shouldn’t need to write novels about how your code works, it should be readable and easily understood even for a Junior developer. When code is over-abstracted it can be difficult to track down the root cause of bugs. Personally I’d rather read code than documentation about the code. Abstraction also adds complexity. Anyways these are just some of the things I’ve learned so far in my career, and it seems this type of knowledge is a bit scarce these days (I’m trying to hire right now haha) All the best to everyone out there and happy coding! May your days be bug-free with happy customers :)
@HealthyDev
Don't be distracted by language syntax and coding patterns - habits are what makes a senior programmer! Here are some of the best one's I've learned. What are yours? ►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → https://jaymeedwards.com/access-techrolepedia/
@richardknouse618
I have been programming over 45 years. In too many projects if have seen a rush to produce visible surface results without first building and testing out the functional foundation. This is because management typically has its focus on visible features and doesn't appreciate the art of well structured code. Each sprint should include development of foundation function in anticipation of rolling out features in future sprints. This goes along with your recommendation to bury the refactoring effort so that management doesn't sabotage it.
@simonekleinschmidt346
As a project manager I cringe about "don't make documentation and refactoring additional tickets because they might be axxed", not because it is wrong, but because I remember how often I fought for these tickets because I knew they would work for me in the long run. (and often got defeated anyway, so you are right)
@jtkilroy
My second comment on this great video. I met a guy that was working at my old employer, but didn't know it. After being introduced he asked me if I used to work there. I said yes and he went on about seeing my name every day in all of my 20 year old code. Made me feel really good about my work.
@gligorhoria
I'm really glad you started making videos again. You teach things we can't really learn from anywhere else.
@shivsticker9680
As someone who does a bit of Dev and Ops, I sincerely believe your comments about refactoring are very true for the Ops world as well. When there is an opportunity to automate a manual process and it keeps getting pushed off by management in favor of the latest feature, the only way to get it done is to simply do it. Getting that type of improvement work done makes me more excited to go to work, and makes my job and my team's jobs easier.
@SpaceMonkey23101
“Programs must be written for people to read, and only incidentally for machines to execute.” - Harold Abelson, Structure and Interpretation of Computer Programs
@janhanson6296
I think putting together good commits is an often overlooked skill that can make code review 10x easier as well as being something that can be referred back to when getting into a codebase for the first time (or indeed the 10th time). Making sure that commits are granular enough to be digestable as well as conveying intent properly rather than just a list of what files are changed and a wordy replication of the diff.
@AlbertoSalviaNovella
Hey nice guitar skills! I have two extra habits: 1. Reason the code in the smallest increment that adds value. 2. Fix the past before continuing into the future.
@travisSimon365