Honestly, the thing I hate the most about IT is how bad it is while no one admits to it.
These are problems I've encountered at several companies:
* No budget for tooling. Be that software outside the ide or be it for hardware.
* Cargo cult is so much bigger than anyone will ever admit.
* The lack of caring about other departments. We're a team and we need to work as a team so the company can make money to pay our salaries. I've seen it to the point where one guy was willing to cause two departments weeks worth of work to avoid doing two days worth of work.
* The amount of stuff that is just broken, people keep complaining about it being broken and it causes a pile of hassle for other people but just stays broken. Or it's point out it's broken and a big meeting is called to deal with it and then nothing is really done.
* The amount of people who don't know what they're doing. So many people seem to have 1-year * x experience. They reach a certain level and they just stop.
* The amount of people who don't even know what they're talking about - https://toggl.com/track/developer-methods-infographic/ a prime example, kanban is literally how they make cars it's we work on one bit and the next area deals with the next part. The image should have a car manufactoring factory as is. But instead they have nonsense.
* The amount of patting themselves on the back saying we're doing a great job while the system sucks and nothing is getting better and employee churn is sky high.
Honestly, I think if people from other industries worked in IT for a year they would be completely shocked at how crap it is. I don't even think the hiring part is wrong, I think the entire management process of IT is wrong and causes more chaos so you end up with people who are heavily specilised in tools who are considered expert engineers but can't read UML.
> The amount of people who don't know what they're doing. So many people seem to have 1-year * x experience. They reach a certain level and they just stop.
Part of the problem is because people only look at years of experience at all, and recruitment often inflates the requirements. I don't need 5 years of work experience in .NET to modify an existing application with very defined and clear boundaries: within a few months, I can easily read what is happening already and mutate the application within the set boundaries. 5 years of work experience is what I'd need to set up an application the size of Stack Overflow from scratch in an acceptable timeframe.
What we have now is a recruitment procedure within the industry which overemphasizes ticking boxes without looking whether they can actually deliver. We have so many quality online sources available, any half-competent person can read, copy what is happening, use it as a foundation and then change it to their specific needs, producing actual applications. You might not cover the edge cases (a specific cryptographic problem here, an suboptimal solution there, etc.), but that really isn't that different from most of the crap software that's getting shoveled out into the open today.
The biggest problem is that there is no baseline of competency. Seriously, when somebody asks for minimally passable competency for employment as a software developer what do you point to in 5 words of less? Software doesn't have that so instead you get a bunch of posturing and smoke signals. Seriously think about how you would explain this to your non-developer uncle who is an educated professional of any other industry.
Think about it like this:
What is the minimal passable qualifier to be a lawyer: a law license. What is the minimal passable qualifier to be a truck driver: a CDL. It is illegal to do those, and many other, jobs without the minimum qualifier.
Worse is this tooling bullshit. No carpenter or mechanic creates a resume detailing their job experience using a screw driver or a hammer. Those are just assumed. If a candidate felt the need to mention stupidity like that you don't hire them. For some reason software has that backwards which invites and encourages incompetent people to apply and degrades competent people to compete with unnecessary stupidity.
I can expect this experience in tooling if the tools were remotely difficult. They aren't. What's more, teams are documenting their tools much better than before, and many are putting strong emphasis on being able to search the right terms and implementing it before the end of the week. Whatever topic or problem I had on ASP.NET Core, the problem was usually solved and documented by Microsoft. At that point, expecting this much experience over such trivial matters, is just being disrespectful to the teams investing all that time documenting and polishing their tools.
Maybe that's the part which annoys me the most. The entire practice devalues everything, no matter who, what or how old you are.
There's an entire cottage industry of expensive consultants that are happy to give your management team fancy but useless PowerPoint decks on how to "break down silos".
>The amount of stuff that is just broken, people keep complaining about it being broken and it causes a pile of hassle for other people but just stays broken
In my experience if someone can't read UML and know how to write a decorator pattern something is up. Honestly, I've never used it in depth but for design patterns I expect people who are "seniors" to understand it. And I expect any expert to be able to look at UML and get the gist of it.
On a side note about design patterns, once as a junior I was at a digital agency and they were doing an in-house tech talk where one of the leads was giving an explaination and he was showing the singleton pattern but what they had allowed for two instances and when I tried to make it clearer to the intern that normally there is only one instance per singleton. The two leads were "Yea but it's still a valid singleton" - it was not but I wasn't point that out directly but continued to make it clear that most people would expect a single instance when talking about a Singleton.
Use cases, activity diagrams, deployment diagrams etc.
Yeah - 'informal' UML use a lot of people are happy with but some things like exactly what some of the features of activity diagrams mean is amazingly badly understood by a lot of people.
I'm ok with the 'UML as sketch' approach, but 'UML as blueprint' is a nightmare that I've never seen work:
Honestly, most of the time I use these diagrams just to give people the gist of what I'm talking about. And my diagrams are super low effort. Think low effort whiteboard diagrams during a meeting style.
> Yeah - 'informal' UML use a lot of people are happy with but some things like exactly what some of the features of activity diagrams mean is amazingly badly understood by a lot of people.
Same with frontend, I give a very rough wireframe trying to translate wtf they are telling me. The end result usually looks very different because once you flesh stuff out IRL there is always a bunch of hills to climb that were unanticipated. And that’s why it always takes 2-3x longer than we first thought.
Especially in a large application with lots of moving and breakable critical parts.
The only solution is constant feedback loops and not being bummed out when your code goes in the dustbin.
These are problems I've encountered at several companies:
* No budget for tooling. Be that software outside the ide or be it for hardware.
* Cargo cult is so much bigger than anyone will ever admit.
* The lack of caring about other departments. We're a team and we need to work as a team so the company can make money to pay our salaries. I've seen it to the point where one guy was willing to cause two departments weeks worth of work to avoid doing two days worth of work.
* The amount of stuff that is just broken, people keep complaining about it being broken and it causes a pile of hassle for other people but just stays broken. Or it's point out it's broken and a big meeting is called to deal with it and then nothing is really done.
* The amount of people who don't know what they're doing. So many people seem to have 1-year * x experience. They reach a certain level and they just stop.
* The amount of people who don't even know what they're talking about - https://toggl.com/track/developer-methods-infographic/ a prime example, kanban is literally how they make cars it's we work on one bit and the next area deals with the next part. The image should have a car manufactoring factory as is. But instead they have nonsense.
* The amount of patting themselves on the back saying we're doing a great job while the system sucks and nothing is getting better and employee churn is sky high.
Honestly, I think if people from other industries worked in IT for a year they would be completely shocked at how crap it is. I don't even think the hiring part is wrong, I think the entire management process of IT is wrong and causes more chaos so you end up with people who are heavily specilised in tools who are considered expert engineers but can't read UML.