1. They set the forward direction for a new technology before it is wide spread.
2. They wait for a technology to become popular / accepted and start to set standards from that baseline.
Both are reasonable paths of implementation given how the pace of changes in technology. <https://goodreads.com/book/show/585474.Writing_to_Learn> A gem can not be polished with friction, nor a man perfected without trials. > it hasn't turned around in cyber fwiw and it's been growing for probably 2 decades, 1 decade in earnest. Perhaps b/c SWEs are a profit center vs. the security
> cost center, there'll be motivations though. IMO the only thing driving sec eng hiring isn't companies realizing career pipelines are messed up, it's regulations
> or getting hacked in profit-damaging ways, and there aren't a ton of companies in those buckets
I don't know from my observations cybersecurity has only been a thing in the last decade outside any defense industry. Before that it was information security and most operations/network security was done by systems and network administrators[1] with the driver being reliability of services verse any concern about the equipment or data on it. > Because the project was big enough to warrant more than one person.
But based on what, the scope? If you weren't familiar with the tech stack how would you gauge that? I understand people can conceptualize frameworks at a high-level. > I have a whole team surrounding me to handle non-technical/non-development incidentals.
Are these the people finding the junior or (5) devs that would be needed. Do they have experience with the framework to know how to scope the project? The hiring of 1 - 5 developers in-house or even as contractors is a labor intensive process so I'm not really sure companies would have just done it based on an idea of an application. I can see where they might have hired early based on winning a contract but they probably under estimated the work if that was the case or padded the cost to account for ramp-up time. > Most companies would have had a lot more budgeted and would have pre-hired five devs.
Maybe you haven't worked places that do spikes or just allow people to develop prototypes without entire scoping documents or hiring people. Also keep an eye on your worth here. If you are saving the company the cost involved in getting (5) more developers then you should be getting a bonus or have decent compensation. A lot people fall in this trap of "saving" the company money as if its their own, its not, and unless you are getting some of that savings you are diluting your current pay and working twice as hard. > Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.
Yeah this is understood as the "mythicial man month" in terms of things slowing down. Adding the wrong head count is a planning and leadership issue. There is nothing stopping teams from being dynamic at a point but that depends on how long the application is going to be supported. Having (5) people now can spread out the working knowledge and workload enough that "no single" developer is holding up forward progress. If you are having to mentor people on the project or fix mistakes then they are the wrong people or wrong skillset for the team. A leader will be able to convey the issue to management and have people let go or replaced. People don't like to do this but there is no reason to keep a failed process going as we are all professionals. Alternatively people above you have accepted this as part of the application development process, it justifies their job, and are fine with it so getting the work done any faster is just a bonus to them. > Those folks have a lock bc there’s a small group of who knows assembly and OSs across multiple systems very well and knows if from a security context.
There is two parts to this. The first is for some of these business in that arena I'm sure if they could speed up analysis to take on more client jobs requiring less labor they would have done so. Second is, what output are you going to provide that wouldn't need the very same people to decipher, validate, or explain "what" is going on?
Referring someone to another food bank or resource is not addressing or owning the immediate problem, which is what the experiment showed. Those organizations failed at their primary objective and instead of re-evaluating why they failed they hid behind process and procedure and how they were being tricked since it wasn't a "real" problem.
There was a proper way to handle this situation as anyone who has worked or called into customer service or tech support where their issue was addressed no matter what the internal structure of the organization was.
[1] https://www.merriam-webster.com/dictionary/miss%20the%20fore...