Current Software Engineers have no Deep Knowledge (Jonathan Blow)

124,184
0
Publicado 2024-02-01

Todos los comentarios (21)
  • @kamilwezka
    My old job: I sit and read books on core concepts. Boss comes and asks: why are you reading instead of working. My old job: wear headphones while trying to code and during deep thinking because I couldn't hear my thoughts in the background of sales calls, constant slack pinging, and people chatting loudly etc. etc. Our head of sales: these guys don't want to learn how the company works about business, and instead they listen to their music at work. Today, you can't focus for more than 5 minutes without being distracted in many workplaces. I am not introverted, but sometimes anyone needs a quiet space & focus time in order to form deep knowledge - it is the same as training a model; it needs time to reach a certain accuracy. Of course, you can optimise and increase efficiencies, but we have organic brains. Besides, businesses expect workers to switch contexts frequently, constantly learning and adapting without any breathing space. How is this sustainable? Perhaps, I am not intelligent, and probably, at this stage, I don't want to be any more. I can learn how to do underwater welding or something. Many years ago I worked as a chef and switched to science and now to technology. Today, I see a technology space as a messy kitchen full of scattered philosophic detritus that clogs all the sinks and often floods the floors. But is it the chef's fault that they can't cook food in such conditions, and they end up most of the time mopping the floors?
  • @tensor5113
    TLDR: Companies don't want experts, they want code monkeys These guys hire and interview for leetcoders, so they get leetcoders then cry about it. Deep knowledge isn't what got me the job, its leetcode. So until these companies hire for deep knowledge instead of toy problems, then keep expecting this problem to occur. Stop blaming the engineers, and blame management/recruiters. There are objective ways to tell who is a good or bad engineer, but most management who hire are not competent enough to understand this. Anyone solving the domain issues that are being addressed in the video are not on leetcode, they are solving the issues with their hands, but these guys still don't hire them.
  • @sujitwarrier4857
    As a software engineer. I agree. The more experience I get, the more I feel I dont know anything. I'm always in a rush to catch up with the industry.
  • @halminnesota699
    I wish someone had a deep enough understanding of audio technology so we wouldn't have to hear this guy breathing directly into the mic
  • @BattlewarPenguin
    A great quote I heard regarding this 'As the island of Knowledge grows, so do the shores of our ignorance'
  • @zenon544
    This is just natural. The complexity of software is increasing, so we have to climb the ladder of abstraction in order to keep up. We can't reinvent the wheel for every piece of software we write - its not efficient and the product will be worse. In the past, there were also polymaths. Today, it is utopian to imagine being an expert in all fields. We have to specialise and build our knowledge "on the shoulders of giants", as Newton might say.
  • The problem is in all subjects, not only CS or engineering, I come from other areas of knowledge and it is the same. The problem that Jonathan argues, is not related to our field, it is a social problem, people need to survive before they know how to do a Dijkstra's algorithm, and it is not good or bad, it is just the reality, whether we like it or not. The rules that determine our relationship with life are not the rules of science or the rules of knowledge, they are the rules of the market.
  • @empereurdigital
    Nerds love "expertise". But in the real world, the market needs people that can get things done for a reasonable price.
  • @BitwiseMobile
    I started out deep. I taught myself Assembler on a DOS machine back in 1985 using the DEBUG command. I used the library for sources of information, but most of it was trial and error. That started a desire for constant deep knowledge. Assembler just wasn't enough for me. I wanted to learn what happens when it sees the opcode for MOV AX, BX. Then I got into electronics and computer design. I majored in CSE (CS and EE mix) in university, and to this day I enjoy creating my own ISA and chipsets. I'm a software engineer by trade, but I design entire systems from the ground up as a hobby. I wouldn't be in this job if it didn't have the depth it has. You can continue to peel layer after layer and you don't really have to stop until you get down to the electron level :)
  • Meanwhile in job posting, we require this very specific framework that came 2 years ago. We need 5 years of exp in that framework
  • @dave7244
    It the same old rant. The fact is that they don't value deep knowledge. They need certain tasks done by a certain date for a particular budget. Jonathon has spent writing a game for years and a custom programming language when he could have just used a decent existing language and a few libraries.
  • We just sit around in meetings and glue things together. If you act like Jon and demand to rewrite everything from scratch, you absolutely will be fired.
  • @egglyph
    I heard the same sentiment about 30 years ago. More or less established guys in their 40-50ies were LAMENTING the new generation
  • Market wants engineers who solve business problems as fast as they can and they pay for it. Naturally it leads to developers in a search of abstraction to solve the business problem sacrificing code quality and resource efficiency.
  • Sorry guys, software engineers don't have deep knowledge because I stole all of it. It's all mine. No, you cannot have any of it. I am a dragon laying on a pile of gold, except the gold is deep knowledge.
  • I wish upon you all just one percent of my breathtakingly deep knowledge. Look at my works, ye mighty, and despair. My knowledge is so deep I don’t push to production, production pulls from me out of respect. My git branches are so well-organized they are studied by botanists and my code reviews are so profound they count as continuing education credits. My wisdom is so deep and fundamental that my programming paradigms have their own philosophical schools of thought. Heck, my code is so secure quantum computers use it to encrypt their data. Woo be upon the mortal that questions the profundity of my deep, deep knowledge of n squared.
  • Actually opposite is true. People usually care too much about understand everything or knowing how to do X the best which leads to insecurity, burnout, quick resignation. Not to mention complexity and amount of things to learn. Learn what you need and try making things. Look how other make things, learn from them. Read books from people who teach how to make things, learn. Adapt it to your own intuitive style and own it. If your program works, does what you wanted it to do, has 0 performance issues and you don't care about scaling it or preserving in the future, who cares if it's 1000 else if instructions of highly abstracts architecture. You will improve with time. Just do stuff and learn by solving issues you face. Don't look into things you might never make use of. It will just be a white noise in your brain. Learn stuff as you need it.
  • @tcurdt
    The problem is really that so little work places care about deep knowledge. It often is cheaper to throw money/abstractions at the wall than to do the right thing. Building on top and on top without cleaning up the lower layers. Engineers have just adapted. It's shocking really when you meet what should be seasoned engineers that just live in their abstraction bubble. Just look at the things done in 700KB back in the days. Now a binary, for software that is barely more than a "hello world", easily comes as a 100MB deployment. Not to say "the good old days", but for better or (rather) worse the focus has very much shifted for solving problems. It's also sad to see how much generational knowledge gets lost and gets re-invented. It often just comes in a different package with new name. The cycles in time are just fascinating.
  • @greed7513
    I want to pay attention but that dude's breathing directly to my ear
  • mediocre scrum practices, focus on deadlines and ambiguous metrics and weekly delivers rather than quality delivery, relience on either FOSS libraries / tools or closed source with awful documentation that break API or ABI on each new update, environment mismatch among teams and projects, serverless and cloud migrations gone bad, non existent or badly applied CI/CD and testing practices, companies hiring in mass for cheap due to nearshoring, salary / responsabillities discrepancy, non technical people as managers and project leaders, pessimal architecure design, tech stack and initial design decisions, new frameworks every month that promise 100x performance and 100x development time reduction and scalability. All of this makes an already frantic and swift industry 100x more so, without proper tools and methodologies to follow up. There isn't enough time to learn everything as we should and are often forced to approach make-shift solutions that will surely break sooner than later.