3 ms·

So instead of training up people with weaker skills we are just happy to see them out on the kerb? They had jobs already, so how bad could they really have bee

So instead of training up people with weaker skills we are just happy to see them out on the kerb? They had jobs already, so how bad could they really have been?

AmericanChopper 7y ago
In my experience, people who want to develop their skills tend not to struggle much with employment. The people who I’ve personally seen get the most frustrated are the kind of people who don’t understand why their colleagues are upset about the 15,000 unfixable linting errors in their React spaghetti, and who proudly announce in standup that they fixed the failing pipeline by commenting the tests out. I’m sure we’ve all worked with people like that, and if they end up struggling to find employment, then yes that does reflect well on recruitment pipelines. They end up producing negative value in any organisation they work for.
- moneywoes 7y ago
  As a recent grad looking to get a job and avoid those errors, do you have any resources or suggestions? Maybe like the book clean code?
  - AmericanChopper 7y ago
    My perspective is highly biased because I started my career as a DBA before moving more into web dev. The things I learned from databases have been tremendously useful first principles for writing other software, especially relating to concurrency and data structures. I’d highly recommend you learn about the first few normal forms and why they’re useful, and how explain plans work in relation to time complexity, you could pick that up from some casual googling. They’re usually presented in relation to databases, but the concepts are useful in any form of schema design. Ive also found understanding concurrency control to be very useful, specifically I learned about MVCC first. I think those concepts are relatively easy to grasp, but are largely neglected by a lot of SWEs. Otherwise in general I just always try to think about the underlying logic of the code I’m writing. If it feels hacky, overly complex or fragile, it probably is, and I probably need to take another look at the problem I’m trying to solve and consider whether I’m approaching it correctly, using the correct tools, or even whether I’m even using the tools correctly.
  - PaulStatezny 7y ago
    I'm not the user to whom you directed the question, but I would answer your question this way: Software developers fall along a spectrum between "caring intensely about quality" and "only caring that their ticket/assignment gets done, with very little regard to quality". These are the kind of people he or she is talking about. This can manifest in a lot of ways. Lack of effort in creating names, adding to the "messiness" of the codebase in various ways, not coordinating or communicating with team members to do things in a consistent way. In general, being content with "quick and easy" fixes that take less work but cost everyone in the long run. People will notice where you sit on this spectrum. I don't know what domain you'll be working in, what company, even what _kind_ of company. But if you soak in the need to have a high bar of quality, you will be able to find the resources that pertain to your language/tools/domain/etc in order to make high quality software. It just takes time. I could rattle off topics to study from the top of my head, e.g.: - SOLID principles of OOP - Learn the benefit of immutable data - Normal forms of relational databases But the best thing is to get lots of experience. With different projects, different languages, different programming paradigms, OOP vs FP. Good books/articles/tutorials help the most when you're applying them to a real work context. If you constantly seek out wisdom about how to do things better as you do real work, you won't be the type of person your OP was referring to. :-)

So instead of training up people with weaker skills we are just happy to see them out on the kerb? They had jobs already, so how bad could they really have been?

AmericanChopper 7y ago

In my experience, people who want to develop their skills tend not to struggle much with employment. The people who I’ve personally seen get the most frustrated are the kind of people who don’t understand why their colleagues are upset about the 15,000 unfixable linting errors in their React spaghetti, and who proudly announce in standup that they fixed the failing pipeline by commenting the tests out. I’m sure we’ve all worked with people like that, and if they end up struggling to find employment, then yes that does reflect well on recruitment pipelines. They end up producing negative value in any organisation they work for.

moneywoes 7y ago
As a recent grad looking to get a job and avoid those errors, do you have any resources or suggestions? Maybe like the book clean code?
- AmericanChopper 7y ago
  My perspective is highly biased because I started my career as a DBA before moving more into web dev. The things I learned from databases have been tremendously useful first principles for writing other software, especially relating to concurrency and data structures. I’d highly recommend you learn about the first few normal forms and why they’re useful, and how explain plans work in relation to time complexity, you could pick that up from some casual googling. They’re usually presented in relation to databases, but the concepts are useful in any form of schema design. Ive also found understanding concurrency control to be very useful, specifically I learned about MVCC first. I think those concepts are relatively easy to grasp, but are largely neglected by a lot of SWEs. Otherwise in general I just always try to think about the underlying logic of the code I’m writing. If it feels hacky, overly complex or fragile, it probably is, and I probably need to take another look at the problem I’m trying to solve and consider whether I’m approaching it correctly, using the correct tools, or even whether I’m even using the tools correctly.
- PaulStatezny 7y ago
  I'm not the user to whom you directed the question, but I would answer your question this way: Software developers fall along a spectrum between "caring intensely about quality" and "only caring that their ticket/assignment gets done, with very little regard to quality". These are the kind of people he or she is talking about. This can manifest in a lot of ways. Lack of effort in creating names, adding to the "messiness" of the codebase in various ways, not coordinating or communicating with team members to do things in a consistent way. In general, being content with "quick and easy" fixes that take less work but cost everyone in the long run. People will notice where you sit on this spectrum. I don't know what domain you'll be working in, what company, even what _kind_ of company. But if you soak in the need to have a high bar of quality, you will be able to find the resources that pertain to your language/tools/domain/etc in order to make high quality software. It just takes time. I could rattle off topics to study from the top of my head, e.g.: - SOLID principles of OOP - Learn the benefit of immutable data - Normal forms of relational databases But the best thing is to get lots of experience. With different projects, different languages, different programming paradigms, OOP vs FP. Good books/articles/tutorials help the most when you're applying them to a real work context. If you constantly seek out wisdom about how to do things better as you do real work, you won't be the type of person your OP was referring to. :-)