Comments by "" (@retagainez) on "" video.

  1. I would argue this video is a bit ageistic towards young people and doesn't really base itself on anything besides having a "good feeling" about things. I think it's nonsense to say that young people who go to hackathons are too young to empathize with customers and thus create the same old social media or to-do list app. How can we not be so sure that young people do this due to inexperience? Maybe it's due to a lack of knowledge for what the market will pay for? Seems a bit silly to me to speak carelessly like this while not realizing the bigger causes of why we see useless code get churned out. Younger developers will be faster, no argument about this, but being fast does not mean anything bad. Being fast could actually reduce risk in the world of software, if you have a pipeline. In car insurance, there's a reason why younger people are charged higher premiums, and it's due to riskier behavior, not necessarily only speed itself. As far as good pointers to learn regardless of age, I think the points the video makes are way too general and unrelated. And a lot of these habits are just behavioral and not necessarily learned. People will just naturally pick these up based on their own interests and motivation. Again, it's just spewing out bullet points but not supporting the point with anything. For example, it'd be far more worth it to say: - Strive to keep your software in a releasable state. Spend time reading and learning about the experiences and wisdom of previous developers. There are a lot of books out there that discuss the topic of working with others and making your work compatible with your co-workers. - Build a skillset that encourages small & predictable iterations. Spend time practicing skills that encourage you to understand the change you make, encourages you to understand what value your change provides, and encourages you to understand how painful your change will be to create. Now take your predicted path and zoom out a little bit, think about the big strategic plan of your development work, understand how your technical work might fit into a non-technical setting. It will be less about bits and more about components, behaviors, and the organization's/end-user's objectives. - And finally, learn to look at the big picture of your company's culture, the customer's requests, and the organization that supports these two. We know that high performing companies correlate strongly with Westrum's organizational culture. We also know there is a general engineering mindset with these high performers and that they incorporate Continuous Delivery, lean software development, and other methodologies. Based on the factors of what keeps a high performing company as a high performer, it suggests that it has little to do with the low-level tasks. Very little to do with striving to "use the debugger, read the docs", very little to do with learning about "AI Code Editors." It has to do with culture. And you can't necessarily teach or learn culture from looking at the trends.
    1
  2. This video leans on ageist stereotypes about young developers without real evidence. Younger devs often build “hackathon” apps due to inexperience or lack of market knowledge, not because they can’t empathize. Speed isn’t inherently bad either; with good pipelines, it can actually reduce risk. The advice given is too generic. Habits like patience or discipline are personal and develop with motivation, not just age. What really matters is keeping software in a releasable state, iterating predictably, and connecting technical work to business goals. Research shows high-performing companies succeed because of healthy organizational culture (e.g., Westrum’s model), not because individuals debug better or know trendy tools. Culture, not age, is the key factor.
    1