I think cleanliness is considered an important metric in large production codebases because companies are constantly asking for new features, and that may result in constant refactoring, having to integrate old features with new ones, coupling and uncoupling features, etc. While it is sad that performance is not an important metric as it used to be, I guess that's the price you pay for the constant need to accomodate the users' demands.

just actually finished watching this here wanted to give my opinion as a non senior engineer ahha. (i hve only have 2 years professional experience lol so what you are about to read litreally has no credability its litreally hust my take haha,) but want to give my take none the less i think becoming a senior engineer is alot as much about your non-coding skills such as intuition and wisdom as your coding skills themselves. Like i think if your coding for long enough youll eventually just develop the programming quality needed to meet the "standards" of a senior developer, so i think its irrelevant to value this metric as a barrier to the title, because if your someone who is anyway intrested in development, its just a matter of time before you get good enough. It might take some people 5 years, might take others 10, so to me i I think, from what i have observed anyways, the real metic is your people/wisdom/leadership and organisational skills. for example how well do you know the entire companys dev operation, not just the FE stack, or the BE stack, but are you clued in with whats being built in the different teams, how they fit in together and what problems are/can/will arise that you have the foresight to see and plan for. i think also engineers who give good feedback in code reviews, do code review without nessecarily being asked to do, things like that. For example where i work. theres this one guy whos like or lead dev.and in terms of raw skill i would say 4 or 5 other devs match him. but this particular guy is in a league of his own just becaus of how on top of everything he is and how clued in he is with every facet of whats going on. I do realise that the definition of senior may vary here, as i guess what i describe is someone who is staff level or tech lead,

You provide examples of natural learning from job experience and then suggest to learn in off-hours. This is a hypocrisy at best. Also, modern tooling is specifically designed so that developer would not need to learn anything. It would be counterproductive to learn anything that is not expected in you job. As long as developer does not hesitate to dive deeper in the stack they use, they would train and solve the low-level problems you discuss with time. Learn what is necessary for your day job and eventually, as lower level problems arise your would with necessity get lower level expertise too. I would suggest to learn organically by rotating projects instead, but I'm not sure today's market is predisposed to provide learning opportunities. This exactly why developers are "senior" - they had time to stumble upon and learn actually useful stuff.

thats an irish accent if im not mistaken. great to find another irish developer channel. (great video btw)

I wish I was born 20 years earlier

Obviously clarification about optimality is a trick condition! If the path is not important return full field traversal constant that would clean the whole field independently of where the dirt is. There it no code more elegant than no code!

9:41 is when i hit subscribe

Great video. I’m an electrical engineering student and understand none of the jargon, but your way of conveying ideas made me sit through the whole video. I have trouble committing to problems that I have doubts in and your video is a great reminder that any consistent effort is worth while.

I have a similar trajectory in my development career and it was the same working on shitty codebases, stepping up to do things i did not know how to do, and being lucky of having more senior programmers that would help me reason through issues. Nowdays so much focus is put on react and all the framework i rarely hear people discussing actual things they are building and the deeper problems they are solving.

100% agree with this.

This is great. I totally agree. I'd rather have one big function than twenty one-liners across three files. Clean code ignores "interface complexity." If your code only has one or two functions, then you know what to call and how it works. It is easier to use that code, because there are only one or two interfaces that you need to understand. The most difficult libraries to use have tons of little helper functions that all do slightly different versions of the same thing.

many seniors are junk

It's funny that this design flaw of React is the issue here. If you had used Vue you would probably have used a computed property here anyway, because it's used there all the time and Vue knows what you used where, so it can rerender only components with an actual change. But even though it is a general design issue of React, I wouldn't say, that it is necessarily a problem in this component. This component could be wrapped in a useMemo as a whole. It could also be calculated in the useEffect, because there it's changed.

Hey, appreciating your input on these issues as another Irish software dev. It's interesting that your learning experiences have become less and less possible over time. The idea of struggling for months to implement a single pipeline is a bit mad as it isn't possible as a junior dev these days. It is sad because it's clearly important to struggle and look for instruction, these experiences are what make you as a software dev.

The one issue with this is that there’s always another layer. You can’t just say “learn the fundamentals” indefinitely without burning through rabbit holes all the way down into quantum physics. Be a bit curious, but at some point you have to say “this is good enough”. Have some interest but don’t let your curiosity consume you.

This guy pretty much said be a whole IT department

The best way I can explain career progression is this: I want to be part of the meeting. Do I need to be part of the meeting. Just give me a summary of the meeting.

Your example was excellent in explaining the issue.

Mooore

There is another important issue you missed: You round before accumulating! A user with 10 projects and 55 minutes in each would get 0 hours worked here. The code is not just slow, its wrong!

"Which I won't comment on" is hilarious

making design decisions has a cost choosing popular stuff is a good and fast heuristic choose your battles

14:36 The issue I have with your statement is that no one knows what a job entails until you get there. Like your plumber example the more exposure a journeyman gets, the more prepared they are for complicated tasks. Part of the journey to Master is set of skills that is industry standard people are required to know to receive that designation. The problem with software engineering is that there is none of that. On top of recruiters and hiring managers don't know how to designate certain standards based on certain levels of experience to adequately assess people.

I see it as an opportunity. Knowing the fundamentals is powerful, but, as always, you need to take initiative to learn them.

Can't relate. Love the wife. Love react. Love css.

Amazing talk! Thank you for sharing🤝🏻

Ah yes, "Blog Driven Development" Clour chasing dreams of infinite expansion chasing clout

Im moving away from Agile and switching to Adventure Driven Development Based on the ideas from AD&D

Ah yes "Book Driven Development" of Clean code I talk about this in my free course how to program from the ground up on my channel

This is so fun... a javascript senior😂😂😂... sorry

I think you're right, but not because people don't want them or can't use them and not because people don't want or can't use junior engineers either. There seems to be no path from junior to senior for most people. If you get really lucky and work somewhere that gives you space and time to grow and the company actually has problems that you will learn something from solving, then you'll do well. If you end up consulting on WordPress sites or whatever then you probably won't. That's really it. Other jobs are similar. You can't become a foreman on a construction site by just installing people's bathroom doors for ten years.

Programming is increasingly becoming a great hobby and a horrible career. You are expected to live, eat and breathe software. You are expected to spend a great deal of time outside of work keeping on top of new developments. Many people don't take into account _why_ they feel a compulsion to continuously learn new things as a software developer. It's usually not something you actually want to do (although many of us fooled ourself into thinking that), but rather something being done to avoid being rendered obsolete. When you take into accout that you must live the lifestyle of a software developer in order to make a living, I find that it is not worth it. You don't see this in other career paths to the extent that it's found in this field. It takes over your thoughts in and out of work, your KZbin algorithm, your interests, your hobbies, engulfing your time for what? Money. If you value money and like working in this field, I recommend adding up all the time you spend thinking about software development outside of work and factoring that into your hourly pay. You will find that it's not as much as you thought it was, and that perhaps it's not even worth being consumed limb from limb by a field that is experiencing a potential mass extinction event in the near future.

I liked your anecdotes and past experiences, faced many similar situations over the years, some of them generated very stressful weeks / months.

The old question, "Do you have 10 years of experience or 1 year of experience 10 repeated times?"

You must love the current landscape of web development 😂

Great video. I recently went through a similar culture shift at a series A startup where directors for Engineering, Product, etc constantly shuffled and changed. It can feel pretty bad seeing a once good culture become not so great. In my case, the culture went from something open with trust into just a complete lack of trust, intense micromanaging, etc. I hope your job search goes well! It really does feel like culture is something that needs to be actively set and maintained. I worked at one series D startup that focused quite a bit on maintaining a good culture (and advertised it all over social media, job postings, etc), and overall it was really good. Of course, some issues naturally arise from being a bigger organization, but the culture overall felt great and open.

Linters are great! There's even react specific ones available for eslint. I think in this example react-hooks/exhaustive-deps would have complained because the useEffect hook seems to be missing a dependency to the user id. If the user id changes, the useEffect doesn't get re-run and can show stale data. Linters like these are a huge time save!

I agree with you wholeheartedly, but I need to see 12 years youtube experience before I can like.

Very good piece of advice.

Thank you.

Great video.

Just WOW! You've killed OOP, sir.

David Hart + Internet of Bugs are the best programming channels on YT!

Same as all engendering stuff… use the tool that better fit the solution. Apply clean code as described by uncle bob in a game or in the algorithm shown here is not the choice to go.

Thanks a lot!

My personal simple rule for "modeling" is that the model I create is to specifically benefit the current problem I'm going to solve, with a minimal level of flexibility by allowing copy/pasting, rather than trying to solve the future problem or extendibility. This sounds extremely counter intuitive, completely against any of my ideas before good amount of experience. But the life lesson of I saw a lot of devs running into is that they try so hard to predict the future and make their model to be future compatible, which turn out to introduce a lot of complexities/abstraction into the current architecture unnecessarily, has no benefits to the current model, and attempt to solve a lot of imaginary problems. At the end, no matter how senior/genius the person was, the real requirement always defeat their "perfect" models. And the original raw version without any models always tends to be more flexible.

At least my code should be easy to extend when I return a month later. 😂 Someone asked for some of my code so they could use it and speed up their own project. Never heard from them again.

I guess the folks applying Clean Code forgot that every piece of it is a trade-off and that one shouldn't add that structure neither to the code nor to the processes around the code by default but only when it pays for itself... and lots of code isn't big or complicated enough to justify bringing in all of that heavy machinery. If you don't have multiple database backends yet then what's the point of abstracting away behind a generic interface the only one you have? Isn't one classic story of Agile the one where they make a wiki but first use a in-memory database while that's plenty for the software to do its job, then switch to files on disk when persistence becomes a requirement and then never end up implementation database storage because there was no real need for it... while in the meanwhile many projects start by first adding the database storage backend simply because it's tradition. I'm not saying this to promote agile but just to say that indeed why add something when there's no practical reason to.

This guy right here == gold advice

Great video! I bet The Primagen is gonna react to this.