Where? Should they drop them at a starbucks out front? Have an employee volunteer their home address? Put them out front at the office? How long should they hold onto the "free" cables that people are going to ask ridiculous questions such as "Do they work? When were they tested?" Are you going to force people to take all the cable or allow random selections? Are you going to waste the cost savings of moving to the cloud to have one of your tech people monitor requests for pickup? What if no one picks them up are you calling the recycler out again to pick up the cables you could have just given them?
Anyone who has posted "free" things online knows it comes a cost, thats the logic part I was referring too. When you work through the scenarios the "logical" conclusion is to give them to the recycler that you already have out at the datacenter for the systems you are decommissioning.
This is such an absurd argument. It's wild that you took the time to write this. But the next time you run into a problem like this, just ask a co-worker. I'm sure they can handle the logistics of giving something away for free.
This is common compliance nomenclature. The only people paying the high cost to have a full sized piece of equipment destroyed are governments or R&D companies with unique prototypes.
The hard drives are most likely being shredded since that is a common practice and certification feature offered by most disposal companies.
The servers are being "destroyed" because thats how they will be accounted for in inventory and tax purposes to account for full depreciation. The company isn't "selling" the servers to the disposal company so they are marked as "destroyed."
Unless specified in the contract the disposal company will sell the chassis without the drives to a reseller or if they are being paid to dispose of the system, they will separate the components and recycle the metal.
The same goes for the power and network cables, they will go off to a recycler, its how disposal companies off-set their pricing.
Remember 10 years ago at big company, the external audit company required picture evidence that the electronic equipment was being destroyed. We requested it to the disposal company, and they sent us pictures of a guy with a hammer smashing a motherboard
The whole situation so ridiculous and bureaucratic
This is correct. Once upon a time, I worked for a company doing this type of disposal. They had 18 wheelers full of equipment show up a couple of times per week. Drives were pulled and put in a pile to be shredded. Everything else was tested and either restored to working order and sold in bulk to organizations in need of cheaper computers, parted out on eBay, or scrapped.
Everything else was tested and either restored to working order and sold in bulk to organizations in need of cheaper computers, parted out on eBay, or scrapped.
Happy to say that my company shreds its old hard drives, then puts new ones in the old laptops and desktops and spruces them up for reuse.
We team up with a local organization to give them to poor children and families each Christmas. IT always sends around a bunch of photos afterward of kids who don't always know where they'll sleep from night to night clinging to a used computer like it's a life ring and they're in the middle of the ocean. I've been told that for some of them, it's the only present they'll receive the entire year.
We don't qualify for a tax break or any other renumeration for this. We do it because it's a nice thing to do.
(I have no idea what happens to servers. Not my department.)
I found that the book "Writing to Learn" by William Zinsser was excellent in convening this process. As noted in the book the author advocated for more writing to be included in all subjects.
Reading, writing and math have been the constants utilized throughout life and as such have been core subjects carried through educational systems. I'm not quite sure what subjects and topics we would be teaching future generations that didn't include reading, writing, math and science. At the very least writing should be included in more subjects. The hidden feature of including writing in all subjects, as you might have seen in your history endeavor's, is improvements in critical thinking, formulating cohesive arguments and a clearer understanding of topics.
There are greater difficulties that people will have to do in their daily lives than being "forced" to learn how to read, write and do arithmetic. Maybe learning the lesson of overcoming smaller, difficult tasks will allow them to adapt to greater difficulties in the future.
To quote Seneca:
A gem can not be polished with friction, nor a man perfected without trials.
This quote mostly applies to people who don't want to spend the time learning existing tooling, making improvements and instead create a slightly different wheel but with different problems. It also applies to people trying to apply "google" solutions to a non-google company.
Kubernetes and all tooling in the cloud native computing foundation(CNCF) were created to have people adopt the cloud and build communities that then created jobs roles that facilitated hiring people to maintain cloud presences that then fund cloud providers.
This is the same playbook that Microsoft did at Universities. They would give the entire suite of tools in the MSDN library away then then in roughly (4) years collect when another seat needs to be purchased for a new hire that has only used Microsoft tools for the last (4) years.
> The frontpage should directly show the list of papers, like with HN.
I disagree. There are numerous times where I have browsed the comments on a HN post where people haven't read the article and are just responding to the comment thread. The workflow for this seems a bit different in that a person would have already read a paper and wanted to read through existing discussions or respond to discussion. With that, having the search front and center would follow as the next steps for a person who read a paper and wanted to "search" for discussions related to that paper in particular.
HN is more an aimless browsing which is a bit different than researching a specific area or topic.
I'm not sure I see this as a reality anytime soon.
> 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?
As an example if you get hacked and you make a cyber insurance claim you are going to have to sufficiently explain to the insurance company what happened so they can try to get out of paying you and you won't be able to say "Xyz program says it found malware, just trust what it says." If people don't understand how the result was generated they could be implementing fixes that don't solve the problem because they are depending on the LLM/decision tree to tell them what the problem is. All these models can be gamed just like humans.
I'm not quite sure I agree that a better LLM is what has been keeping people from implementing pipeline logic to produce actionable correlation security alerts. Maybe it does improve but my assumption is much like we still have software developers any automation will just create a new field of support or inquiry that will need people to parse.
You will start to see this turn around as companies realize they need to go back to the path of entry -> mid -> Senior/Principal. For cybersecurity this is operations and/or development -> cybersecurity w/ focus on either dev or operations. Then at the Senior/Principal layer people can float between things. This isn't too far off from many other jobs, no EE out of school is designing circuits and boards from scratch its debug what Senior EE's have created or problems in existing products, then you work your way up. Its the same with cybersecurity does a person that hasn't developed software start out doing reverse engineering? Does a person develop or approve security policies, devices, network architecture or designs if they haven't every deployed an application or service in production? How are you determining if something is an incident or valid alert if you haven't managed a network.
When money was free companies could hire people for very specific tasks and knowledge areas because it wasn't costing them anything to get the money. This is why lay-offs in engineering, while smaller percentages compared to other departments in the company, are for jobs that are specialized where in previous times it might have made sense to get a consultant or contractor.
> For cybersecurity this is operations and/or development -> cybersecurity w/ focus on either dev or operations.
Fwiw, I haven't heard or worked at any company implementing this pipeline formally. And, cyber teams (or more appropriately, the industry career thought leaders) expecting it to work this way is a large part of the existing issue.
Fundamentally, under this logic one industry (cyber) is relying on another (SWE/IT) to train its entry level candidates. Logical enough.
In practice, some of the issues:
- there are very few roles that are entry in cyber that aren't a large pay decrease for the SWE for a year or two to take. So, many don't take this jump unless there is a clean pivot into appsec or infrasec. Companies needing both of those are small, you largely only see this pivot in tech.
- IT teams don't particularly want to lose their headcount, so outside of excellent manager or very self-steering IT eng, nothing in IT is helping the aspiring sec eng make the jump over.
The end result, to solve this problem
> Does a person develop or approve security policies, devices...How are you determining if something is an incident...
is it's not really solved in a clean way. There's a massive talent gap and favorable mid+ sec eng employment market because of it. Cybersec is already experiencing it, LLMs will make it worse, and I think it'll get worse for devs as well ("How are you determining a performant app if you've never built an unperformant one and fixed it?")
//
which is a long way of discussing
> You will start to see this turn around as companies realize...
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
> 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.
While the hacks are a driver of the cybersecurity field the biggest driver as with all things is insurance companies and cyber coverage. Insurance companies requiring people to be dedicated on keeping up with vulnerabilities, secure default implementations, data restrictions is what is driving the need and companies just want to fill it to keep their coverage or keep their rates lower. Its the typical idea that if you add more software developers or people to a project it gets done faster, when in reality it doesn't work that way. This is why I think we will see a shift back to a more graduated source of cybersecurity professionals. There wasn't a formal path to being a systems administrator or network administrator compared to Computer Science degree -> developer.
Thanks for the astute discussion. Its much better than the "one" line bot responses that you typically see now.
[1] For all the young kids these jobs were renamed DevOPS, NetOPS, SRE, etc. Previously these responsibilities were just part of operating a network.
Fair call-out. To clarify, I swap what I call the job depending on the audience, but IMO the underlying requirements of the job haven't really changed. A SWE/business audience - call it cybersec. At the security cons in Vegas - call it infosec. Obviously there's skill variations within the security needs of the day (i.e. pure "netsec" isn't around as much anymore vs. "cloudsec"). But, skill shortages have persisted across all these variations of the job IMO.
> insurance companies and cyber coverage.
I've primarily worked in tech or finance, and tbh I don't run into insurance topics a lot although it's of course speculated as a possible growing motivator for the field and related hiring. The issue and "signal" I look for with that changing is when will the Fortune 500-style mass data breach actually turn into (a) uninsurability or (b) massive fines. Neither have happened yet, but IMO this is changing.
In terms of security programs I've joined where there was an incentive to hire, it is always something like this, which is what I mean by regulations or hacks driving hiring in my (anecdotal) experiences:
- Want to IPO, Series C tech startup? Must pass SOC-2, must hire security team.
- Horrible hack or very narrow close call, largely stayed internal -> board/founders gets fired up about cyber risk, and it filters down to hiring out a security team.
Why did you think you needed to hire a junior dev before even starting work on the application? I know estimation can be a difficult task but the typical "I'm moving so fast..." type experiences usually mean you didn't or don't understand your tooling or the scope.
Also how were you going to take on a junior dev and a new framework at the same time? Were you expecting them to know the framework?
As the saying goes though the last 20% takes 80% of the time.
Because the project was big enough to warrant more than one person. I have a whole team surrounding me to handle non-technical/non-development incidentals. Most companies would have had a lot more budgeted and would have pre-hired five devs. Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.
> 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.
Honestly it sounds like it wasn't a tool that is needed often, if it was you or someone else would have already written it. Or you don't regularly day-to-day program enough in javascript / python to do this quickly. There isn't anything wrong with that, as you mentioned, you have entry level security engineers that typically handle those tasks. Creating a tool goes fast when you know exactly what you want it to do and don't have to explain to another person all the requirements and pitfalls to avoid based on experience you might have in writing quick scripts. I don't know if this really changes anything.
Lets use some logic here. The disposal company is taking the cables with them to recycle them for the copper wire. Same with power cables.