Slashdot Mirror
Ask Slashdot: What Are Some Hard Truths IT Must Learn To Accept? (cio.com)
snydeq writes: "The rise of shadow IT, shortcomings in the cloud, security breaches -- IT leadership is all about navigating hurdles and deficiencies, and learning to adapt to inevitable setbacks," writes Dan Tynan in an article on six hard truths IT must learn to accept. "It can be hard to admit that you've lost control over how your organization deploys technology, or that your network is porous and your code poorly written. Or no matter how much bandwidth you've budgeted for, it never quite seems to be enough, and that despite its bright promise, the cloud isn't the best solution for everything." What are some hard truths your organization has been dealing with? Tynan writes about how the idea of engineering teams sticking a server in a closet and using it to run their own skunkworks has become more open; how an organization can't do everything in the cloud, contrasting the 40 percent of CIOs surveyed by Gartner six years ago who believed they'd be running most of their IT operations in the cloud by now; and how your organization should assume from the get-go that your environment has already been compromised and design a security plan around that. Can you think of any other hard truths IT must learn to accept?
suckers haha
The Cloud is your enemy. Fire anyone who offers a "cloud" solution before offering an in-house solution, because I can guarantee you that "cloud" services are only half as efficient as running the hardware in-house. The question really is where do you want your data to be.
If you have privacy concerns (eg credit cards), then machines dealing with credit cards should be co-located in a high-security data center that you know who has physical access to it. If you are simply serving cat videos, then cloud-away, because nobody is going to care if a cat video is slow due to bad provisioning.
But every time, it seems like I have to fight someone as to why it's cheaper to own or lease the hardware in-house rather than "cloud it", because cloud services are not as scalable as you believe it to be. The "cloud" only scales two things efficiently. CPU "TIME" and "Storage Capacity". If your IT is not concerned about these, then it doesn't belong in the cloud. If you are concerned about security or latency, those must never go into the cloud.
If you are crunching numbers, it is cheaper to borrow the CPU power of 500 computers for one day than it is to buy two computers and have them take one year. That is where "cloud" computing is supposed to be used.
Instead we have the morons of IT management trying to put everything into the cloud so they can eliminate IT staff, and the cost of doing this is that when mistakes are made (eg equifax) , nobody knows how to fix it, and it costs substantially more to fix by hiring new staff just to solve one problem.
>> What Are Some Hard Truths IT Must Learn To Accept? ...that IT is not engineering, and that engineering is not IT.
in HTML. There. I said it.
If you want to be a sysadmin these days, do the devops thing. Which basically means you are a sysadmin who knows how to write deploy scripts for AWS. Pays a lot, though.
"First they came for the slanderers and i said nothing."
Then don't fix it. Seriously if something has been working fine for years, don't meddle with it.
Only the State obtains its revenue by coercion. - Murray Rothbard
The single biggest predictor of project success/failure is the quality of the people involved.
However, most firms are bad at recruiting and maintaining top-quality people. Often, they chase the best ones away, resulting in the Dead Sea Effect.
Finally, "In starting a new software program, all the important mistakes are made on the first day." (The Art of Systems Architecting, Maier & Rechtin). ..bruce..
Bruce F. Webster (brucefwebster.com)
I used to be an IT person, but have spent time in the humanities too. From that experience, I'd say the biggest lesson of all is that often more technology is not the solution. And that as much as we nerds like to think we are rational, we often fall into the trap of being religious about our belief that all a situation needs is more tech. The humanities - ethnography, sociology, philosophy - have valuable insights to offer into the complexities of human society.
Now when I see thing like the blockchain I see projections of ideology, and very little real understanding of the complexities of politics, ethics and social norms. To a nerd, all of that is noise, something that ideally shouldn't be there.
To learn more about this, search for the 'technological determinism vs social contructivism' debate.
IT going forward doesn't need a dozen people with BS degrees. When you're building a house you only need so many civil engineers and architects. At some point you need a fleet of plumbers, electricians and general contractors. Some people insist that a BS is required so management finds the cheapest BS they can. For 10% of my job I would love to hire a 17-18 year old apprentice and just train them in the hands on tools.
I don't need a BS. I don't need an Indian. I just need someone thirsty and willing to learn. I was lucky enough to have an engineering 'apprenticeship' at 16 and it influenced the rest of my career. It was hands on "do this" style learning, exactly how you see journeymen training apprentices.
There will always be a need for advanced degrees but the ratio of degreed:apprenticed needs to change. Doctors have moved to train physician assistants, RNs, and a host of other positions to do most of their job so they can concentrate on what they were trained to do.
If you're a manager looking for 'cheap labor' start talking to the local voctech high schools. Factor in rework and communication 'costs' and pay them well for their age. You'll come out loads ahead. They'll have relevant job experience for the future and you'll have cheap labor. If you have someone set to retire in 5 years just have the 16 year olds shadow them and do any work that they can.
You'll have 'cheap' labor that knows your system inside and out and you can pick the best to hire after HS. It's how all of the CNC and tool and die shops in my area do it. Kids wrap up highschool and get hands on training in something they're interested in. After HS the CNC shops have 18-19 year olds that are getting paid well for their age with no debt.
Software engineering cannot be squeezed into formulas for plugging and chugging.
The most banal, junior school/Jeopardy linguistic construct ever.
E.g. "What are some hard truths your organization has been dealing with?"
You could say
"What hard truths has your organization been dealing with?"
Or, imagining the set of hard truths being finite, you could even say "Which...".
all hail
While there are a lot of problems with the way IT is done in companies today, my experience has been that the companies who pay the least for IT (as in smallest IT staff to general staff ratio) are those companies that encourage honesty, thoughtfulness, and long-term planning. I've worked for a few - at one place, a handful of staff supported 4,000 workers and had time to blab at the watercooler. But they could do this because the company was remarkably consistent about resisting IT fads, and instead looked at IT purchases from the standpoint of, "Yes, but what am I going to get out of it?!" They paid their employees, the vendors, not so much.
Those companies which view IT as a cost center, in my observation:
pay far more than they need for what they get
follow the latest fads in IT
are continually under the gun to cut costs
constantly overwork their employees,
deliver much worse service overall,
and suffer from seemingly constant IT failures of one sort or another.
For some reason, those companies which view IT as a cost center rather than a strategic asset always seem to be falling short of their goals.
The society for a thought-free internet welcomes you.
You lone wolf, cowboy types are losing the war with your NIMBY ways. There is no spoon.
If you don't work for a tech company, you are a blue collar worker not a white collar worker.
Even if you do work for a tech company, if you are not a manager or a high level designer, you are a blue collar worker.
Basically, we are more like plumbers than doctors.
We really should unionize.
excitingthingstodo.blogspot.com
1) Agile is bullshit
2) You do not need to have meetings every day
3) Standing up for a meeting is utterly ridiculous
4) Iteration Managers are a very poor replacement for Project Managers
5) Scrum Masters are a crock. You should not hire these people
6) Kanban is a bullshit methodology
7) Hotdesking sucks. Treat your staff well and give them their own desk.
Your codebase's primary job is to attract and retain top talent. Whatever the fuck you want to sell or buy or disrupt or facilitate is secondary, if you can't get people to write and maintain your code.
You could have a hideous frankensystem that grants golden penis wishes and you will go bankrupt trying to maintain it if you don't let those two skinny guys and that fat guy convert it to Rails, then Angular, then React every 6 months.
Throw it away, Reboot it, Buy that software, Replace that finicky ___. Don't be the "hero" who spends 3 days debugging something which can be replaced for $500.
You mean convert all your API's into JSON calls and spin up gajillion web services? Why? That increases complexity. Native-app-language-to-native-app-language is much easier than app-language-to-JSON-back-to-native-app-language.
Can't cloud do monolith? If not, what's stopping it? The performance bottleneck usually is and should be the database anyhow for must CRUD apps. Kajillion web services won't solve that. The CAP Theorem (Eric Brewer) limits your options and probably shouldn't be an app-side concern anyhow, but mostly a database side issue.
This kind of hype created a bloated stack in our org that requires dealing with 4x more code than a normal stack would. Nobody can give practical examples of the use of such splitting: they just spit out vague buzzwords stolen from Dilbert's boss, or dreamy shit like "what if we grow to Amazon.com size"? -- Yeah Right. We are more likely to get hit by a meteor while buying a lottery ticket on a unicycle.
Plus, these extra web layers seem a security risk: more doors for hackers to pick the locks of. Who is spreading this microservice rumor/hype? Russians? Microsoft marketers? Wrox? Knock-it-off!
Martin Fowler said:
As far as general IT advice:
1. Data tends to outlive application software, so focus on good data.
2. Be wary of wasteful hype. Let somebody else be the guinea pig. When that somebody else has it running well, THEN borrow the idea.
3. Books are judged by the cover for good or bad, so throw the executives a pretty bone for a few high-visibility parts of a system, but keep most of the regular stuff (grunt screens) in something easy to create and maintain. Don't drag down the entire system chasing eye-candy and UI fads. By the time you're finished, it'll be obsolete anyhow.
4. "Separation of Concerns" is a myth. Most non-trivial concerns inherently inter-weave among each other. You want to manage concerns well, not outright separate them with thick Trump Walls.
Table-ized A.I.
1. The whipped cream in the bathroom is not whipped cream.
2. We cannot escape ourselves.
3. And sometimes, the cat door... is closed.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
1. State actors never have your own best interests at heart.
2. Frat tech boys will always get their feelings hurt. And whine whenever they aren't winning massively.
3. Comment your code. Always. And stick to naming conventions, it saves a lot of time - for you, and for others.
4. Low cost index mutual funds and ETFs will always outperform actively managed stock and bond funds. Property will always outperform all of these in areas of high population and job growth. You can't take it with you, so don't buy a house you don't need until you actually need it, and never look back.
5. Lists are for people who have problems. Which is, quite frankly, everyone.
6. Take showers and brush teeth/hair. Don't wear shirts or underwear more than one day. Keep spares at work or a gym if that's hard to do.
-- Tigger warning: This post may contain tiggers! --
Plain and simple -- IT costs money. The people who operate and implement IT cost money. Every bit of IT that gets implemented, from email to that fancy CRM system require money to do right. Even if you move stuff to the cloud, outsource or push it out to front-line staff to do it themselves will always cost money.
The trick is to make that money you are putting toward IT to good use. You will spend it regardless if you make it your competitive advantage or not. So, the smart companies use technology as their competitive advantage rather than just as a cost center. Making IT a competitive advantage costs a bit more, but ultimately it will put more money into other parts of the business.
You can't fix stupid.
I'm 42, so I'm officially an old fart when it comes to my IT job. I'm in a senior engineering/systems architect job and one of my favorite aspects of it is my unofficial duty to impart wisdom on the newbies. My "hard truth" about IT that surprisingly few people truly grasp is that you can't get comfortable being the expert at one particular thing and coast. Even 10 years ago you could do that...I know so many people who make more than I do jumping from contract to contract doing CCNP-level router work or being the "EMC/HPE/IBM storage wizard." The formula for success used to be to pick a vendor, steep yourself in the technology, then get and keep certifications while learning what's new every few years. This is rapidly going away...regardless of what you think of cloud, CIOs hear the magic word "OpEx" and suddenly all that on-premises hardware and knowledge is out the window. For years, I did a combination of Windows Server, Citrix XenApp and System Center as my core skills, while trying to learn as much as I could about other areas. Even that has changed so much in the past couple of years...desktop apps are being replaced with web apps, containers, APIs, anything that abstracts the client layer and makes it look and act like a smartphone.
These days, one of my jobs is to do the systems design for a huge project in Azure. Anyone thinking they can just pick up a cloud provider's stack of tools overnight is in for a bit of a shock. Couple that with the fact that all the cloud vendors are releasing whole new features every week and existing features change almost as often. Part of my job has been trying to get as many of our engineering staff on board for learning cloud stuff, and it's been a challenge with a couple of people.
Keeping up with all the knowledge needed to be the guy they keep on staff when all the routine work is offshore is hard. I have had to dedicate a lot of off-work time to it, because no company trains their staff anymore...one of the things I hate about IT not being recognized as a real profession. The reward for doing this is a very interesting job and, not surprisingly, a higher-pressure firehose to learn from. :-) Being a dad on top of this is tough also...it requires lots of time management, late night reading and watching videos at 2x speed to do this and be a functioning parent.
So yeah...if you want to keep an IT job, especially as things get more and more abstract, broaden your skill set and learn as much as you can get your brain around.
San Francisco tech startups have a serious problem with gender equality nearly as bad as the one in Hollywood, but the rest of the United States doesn't, so they can shut the hell up with their hypocritical political garbage.
You are a red line on the budget. You are nothing but an expense Your department just beg and grovel to justify its existence at every turn.
When something breaks, and you fix it, the value of fixing it will not be seen by the company. They will only see this red line on the budget fucked up and expanded that red line even further.
DevSecOps is where the industry is headed.
100 REM PISS OFF CODE FASCISTS 200 GOTO 100
I've worked on IT problems for a very long time.. coming up on 30 years here soon. In all sorts of contexts, academic, government/miltary, ISPs, ASPs, cloud providers, SaaS entities, traditional IT departments, telcos.. you name it. Ever work at a company that has 64 different billers and no plans to ever consolidate? Ever work on an awesome tool only to have it replaced by index cards because the guy in charge was afraid of computers? Ever build a perfectly capable monitoring/management platform only to have it replaced by an entirely substandard version because yours 'wasn't invented here'? Ever watch as a vendor takes big chunks of a companies money every 3 years because no one remembers the last time said vendor couldn't deliver even though it was only 3 years ago? Ever watch project after project fail because anytime any modicum of project management is applied or development methodology attempted all progress comes to a screeching halt? I have and I can go on endlessly... with examples of IT failures and very rarely, IT's successes. To sum it all up, to me, all forward progress in IT is made by people who actually know what is going on ( both from a technical and from a business/political/social perspective) .. and generally, all hard problems associated with IT are caused by the poseurs and the leeches ( in either domain ). 2 examples of poseurs.. execs that use vendors to do everything for them, including thinking for them .. or the 'X specialist' that refuses to learn the 'Y domain' because of the 'religion/supposed magic/history/tradition around X' .. 2 examples of the leeches.. the person that blocks any attempt to introduce something new or fix lingering issues because they want to protect their job.. or generally 'project managers/scrum masters/etc.' For me, the team/module is too big if you can't run it or extend it with 8-12 people .. beyond that the overhead causes everything to cave in ( not a new concept .. see MMM's surgical team concept from 1976) .. I can go on endlessly.
The low point of the poseur/leech problem is this recent love affair people have with 'imposter syndrome'... it's as if the poseurs and leeches are wanting desperately to rationalize their reason for hanging around and have created this sad justification. Let's rather focus on the 'burden of the expert'.. having to constantly claw your way thru all the artifice and detritus stood up by the imposters and instead find a way to clear these folks out, make IT into a real engineering profession, and then finally automate and converge IT away as was promised long ago .. and not have IT itself leech off the system forever with teams re-developing every possible thing over and over again in the next new fad methodology or language. Sorry for the rant.. IT could go on forever. :-)
A June 2017 survey of 300 IT pros found that 80 percent said the cloud wasn't meeting their expectations due to problems with security, compliance, complexity and cost. According to a January 2017 survey by cloud management firm RightScale, from 30 to 45 percent of enterprise cloud spend is wasted.
No shit, Captain Obvious. The whole, "Giving The Keys to The Kingdom to Someone Else" idea (otherwise known as Cloud Computing) was idiotic from the start. Of course it was, is, and always will be, costly and inefficient. It boggles the mind that otherwise (presumably) smart people would be so stupid as to buy into that particular brand of snake oil.
The only surprising thing in this section is that RightScale stopped at 30 to 45 percent. In my experience, the waste (meaning absolutely no benefit for the dollars spent) is closer to 85 to 90 percent.
You are constrained by your circumstances only as much as you are willing to go out on a limb and risk failing.
And web management GUIs are a sickening fad of instability.and inconsistency.
-
Windows, Mac, Linux, you name it... it's not secure, by design. None of them implement the principle of least access (POLA). All of them are default permissive environments which makes it impossible to specify at run time the extent of side-effects allowable from a given process.
My running estimate is 10 more years before people wake up and start re-engineering things to shift paradigms. Until then, chaos will continue.
I do not block ads. I do block third party scripts.
Unless you are in some kind of Internet business, you are not a line department. You are a support department. just like the janitorial service. You are being paid, not to pursue your own ambitions, but to make other peoples' ambitions come true. Maybe you get to do some professionally interesting things along the way, but to be a professional you can't let that affect your decision-making.
Perhaps a better analogy than the janitors would be the organization's lawyers. Corporate counsel a highly skilled position, but as a lawyer your job is to look after the interest of your client. If you decided to take a particular legal course because it involved a new and interesting legal theory that would be legal malpractice, but IT people do that sort of shit all the time.
I have found working in the staff role very rewarding; you can even have a transformative effect on an organization. But if you're not interested in what the organization does and helping the people who do those things you'll never be good at your job.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I always wondered why the government moved managers around every two years. The reason is to avoid the possibility of ever holding someone accountable for fraud, waste, and abuse on mismanaged IT projects. As long as there is a culture of âoeIt was the previous management who let the contract go to hell there will never be any changes.â
The following is the fact that everyone should realize. âoeThe IT Department - delivering you yesterdayâ(TM)s technology tomorrowâ
IT's Glory Days have come and gone.
But actual experts are expensive. Stay away from IT "security experts" that cannot code, that cannot configure a network or a firewall, that cannot administrate a system, mailserver, DNS server or webserver and that do not understand how crypto works and what it can and cannot do. I have seen far to many of these people and they universally make things worse in the long run instead of better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If you've got ten operations employees and ten developers, an you replace them with eight people doing the same work, then that's DevOps. It really only applies if your developers are doing web stuff so that there's a little bit of overlap when seen from a mile high.
I was at one job in the 90s when the system and application developers were merged with the customer support team. All of the devs needed to spend time phoning up angry customers, and all of the customer support people had to fix up bugs. It only sort of worked because the customer support did know how to use the scripting language for the product, but us devs were absolute rubbish at talking to real people. That experiment only lasted a month. (later the same company took a few new developers who started that week and turned them into professional services, but that only lasted a day because they all quit)
I was working contract at the HQ for a x86 processor maker (yes, you can probably guess who) a couple years back and IT had banned any program which attempted to even READ from the Windows registry...which I found out when Visual Studio batch file (to setup its environment) complained about being able to find some of its installation paths
Rather than talking to IT to fix the problem, my boss pointed me to a network location which had a .exe to enable all registry writing...and a set of recursive directories for each OS going back to the 90's when it was a simple VBScript with the company's logo.
Hacking a solution to bypass IT had literally become the de facto design pattern for over 20 years.
(FWIW, I don't even blame IT...every I talked to was both nice and knowledgeable, but it was clear they were being handled like a commodity and had almost zero free time to help with anything that wasn't in an explicit ticket.)
-- Political fascism requires a Fuhrer.
The days of you being able to be condescending, or rude, or throw tantrums because your technology or architecture was not the chosen one just because you're "just in IT, ignore him/her" are long, long gone.
Executive teams don't care if you're the only person who knows some obscure system anymore. They don't care how clever you think you are or how your CV for sure proves that you're "in the top x% of all developers". Software systems are not so much voodoo to them now as they used to be and they are perfectly comfortable canning your a** if you don't play well with others.
At the very least, your career projection will end if you think behaving like Dilbert is cool (if you just think Dilbert is cool you have a whole bank of other issues which may or may not be career threatening).
I taught grads for a few years and was asked over and over for one piece of advice to help with their career...most were expecting "learn java" or "learn python" or "learn X" but it was always the same...don't be a d*ck and your career will be just fine.
Depends what sector of IT, but it's an ungrateful job.
You have to constantly learn and improve. ... and treated that way too.
Companies tend to hire younger people they can exploit more.
Companies tend to hire cheap barely skilled labor over investing in quality people.
Management has no idea what they're doing, as most of them don't understand IT at all.. they just know buzzwords such as Agile, Cloud, whatever.
If you're in some kind of NOC, you're basically a plumber.. and treated that way too.
If you're programmer you're basically just a drone
Etc. Etc.
I've been in IT since 2001, it's getting worse and worse (at least for me) to the point where now at 32, I'm trying to make something of my own (product/service) so I at least I don't have to deal with bosses, management, agile standup bullshit meetings, or discussing cloud providers.
Hopefully I will, otherwise I might commit suicide.
For reals, broham?
IT is a support function - it's job is to keep the rest of the company moving.
All the security in the world is pointless if the actual task at hand can no longer be performed.
For example, my corporate IT policy forbids me sending "files" to customers. It enforces this by not allowing FTP access, and not allowing binaries, archives, etc. to be transmitted in email messages.
This is kinda funny, because my job is writing software. I'm literally being paid to create binaries and send them to customers - something I'm no longer allowed to do. So what are my alternatives? If I'm remote-debugging an application in another country, should I just send them USB sticks or CDs every time I have an update? Or should I just fly out and stay in a hotel a couple of days each time?
Oh, and if someone sends me a binary or an archive (or an SVG drawing - very dangerous, those), the mail is simply disappeared by the corporate email system, with neither a message to me that this has happened, nor to the customer that their message wasn't delivered. About the only thing I can think of that is even more secure is to just abolish email altogether.
Since we switched to Skype for Business we haven't been able to make phonecalls either, so if they removed email, in any practical sense I could just stay at home. Nobody would notice the difference anymore...
Anyone thinking they can just pick up a cloud provider's stack of tools overnight is in for a bit of a shock. Couple that with the fact that all the cloud vendors are releasing whole new features every week and existing features change almost as often.
The key is to keep things simple. You really don't need features like AWS Lambda, even though they are really fun. If you treat the cloud as a plain vanilla way to spin up and down servers, then you can build a robust, portable architecture that won't need to be rewritten at the whim of a vendor.
"First they came for the slanderers and i said nothing."
You're overpaying programmers for the shitty code they produce.
Programmers producing shitty code? The answer is clearly cheaper programmers!
SJW n. One who posts facts.
Here is my some so far unlisted experiences from me, after 16 years in IT in various roles - right now as IT Strategist in a large organization.
1) All IT solutions are more or less temporary and constantly evolving. Continous evolution of the systems environment is generally less risky than big projects that aim to replace several systems. Often, sticking with your old systems and adding, replacing and removing functions works best.
2) Getting new systems is easy compared to migration from old systems and decommisioning.
3) Collecting requirements from users are generally very hard and often fails. The best requirements specifications is a current systems or sometimes an advanced excel sheet that has outlived itself. These can be seen as prototypes.
4) Large scale IT operations can save money but it also adds maintenance complexity, which costs money. The IT cost is not what matters. What matters is the total effect on business.
5) Technical arguments to replace a application should be vetted carefully. If someone proposes that a new system is required because the old system is based on legacy COM+ or some other obsolete framework, this is often incorrect. It is very often much cheaper to replace different modules in applications.
6) Measure as much as possible. Website uptime, usage statistics, server usage, response times, firewall rule hits, database requests, etc. Users and system administrators are very ofter clueless on how much their application is used or if it works properly or not. The IT department should set up a good measuring framework. Only the experts even know what can be measured.
7) Don't overdo ITIL or similar frameworks. If you have more people on managerial roles than technical roles, you have problems.
... time and time again, for all of us in IT:
The world doesn't revolve around you.
IT may be a cornerstone, but it's very often not the actual business. If IT falls, personnel will switch to pen and paper. If everything else fails, the best IT is pointless.
Don't over-estimate your own importance.
We suffer more in our imagination than in reality. - Seneca
1. Management doesn't understand shit about IT
2. Management is always right
Slashdot, fix the reply notifications... You won't get away with it...
You're overpaying programmers for the shitty code they produce.
Programmers producing shitty code? The answer is clearly cheaper programmers!
No, clearly the answer is to keep doing what's being done now because it's working so great.
I think this is right, but choosing a vendor/technology to beef yourself up on, especially on your own time, feels like playing roulette -- you have to put it all on 23 red, essentially, to develop anything remotely like "expertise" and then *hope* that whatever you've invested in is "the thing" that your management, industry to even employment region, decides is the thing they will invest in.
It used to be a higher-percentage bet that whatever you invested in would have a good chance of paying off. But I've seen too many people buying into something only to find out it doesn't pay off because it turns out to be marketing BS or winds up in reality being not the economic choice people with money want to make (or, you seldom lose betting that management is cheap).
The other thing is that I mostly reject the notion that self-investment in most technologies produces anything like expertise, with the possible exception of software languages where there's a lot more opportunity for in-depth implementation. I run into plenty of people who are certification/video/example experts but who really have zero grasp of the logic/rationale of operational choices and real-world applications. And in many cases, it's not their fault but the reality of extremely expensive equipment, restrictive software licenses, and the hard reality of separating hype from fact in real-world implementations.
For a lot of IT technology you need a lot of time and an awfully big sandbox to think you've developed any "expertise" in a particular technology. I'm increasingly convinced that only real-world production experience counts as actual expertise.
The whole point of this thread was that some jobs unnecessarily have advanced degrees as prerequisites.
If employers do not want broad-based knowledge and education, why do many IT jobs require college degrees?
Yes, employers do list jobs with very specific requirements - many times after listing a broad based college degree requirement. This tells me they want a formally educated individual with specific work experience.
The trades have similar requirements. I know many certified technicians (HVAC, Automotive, and Industrial) who have either two-year engineering educations or VocTech and their employers still require job-specific experience along with the broad education.
Are there some employers who only want one very specific particular skill? Yep - and I'll bet your "career" at those employers will not last long - as soon as that technology is gone - so are you.
In a large organization, non-IT employees will outnumber IT members 100:1. IT members will be focusing on a billion different things throughout the day... but Janine in Accounting is freaking out because her monitor is flickering and Allen, her assistant, knows how to troubleshoot but got his head bit off the last time he unplugged a cable. So IT has to send someone over to give a once over and hear the bullshit from Janine about how this has completely ruined her day, etc.
Get to know Allen. Allen knows shit. He just doesn't code. Use Allen, don't hate on him.
Bring Allen in to meetings when discussing the new procurement system you're building for Accounting because he knows enough of the Accounting side and enough of the IT side to bridge the gap for both groups.
... there are no 'musts.'
Requiem for the American Dream
Don't have a lot of Agile experience, managers seem to love the "latest" (it isn't all that new) buzzword. I've found a lot of the principles are done anyway with a good back and forth relationship with the developers. However... I've noticed that doing rapid Agile type development exacerbates some of the existing challenges in testing, namely regression testing. Basically you have to be testing ALL the time. I'd have to block off essentially all my time for testing, whereas in less iterative approaches, you test for a specific release, go do other stuff you have to do for your job, then when the time comes, do some more testing on a release.
One of the PITA of testing that everyone will understand is regression testing where whatever it is that is being worked on, breaks something else, many times with no seeming connect (at least at the time). Anyway with more discrete releases I think it is easier to nail this down. However when there are constantly releases, of which any of them could break anything else, you just end up testing ad infinitum for the duration of the project. Which is fine if you have one project you work on. If you have a dozen projects all on the go, it becomes untenable. So I guess it is more of a resources issue that management might not understand. Also some of those principles of Agile basically box up failures into critical or not, which one would do normally anyway, but again due to the numbers involved, some of those non-critical can snowball into major issues, to which at that point it's too late. There seems to be a lot of, well with Agile, you just got to live with mistakes and move on and do more Agile, etc... Doesn't make for a very stable release ever.
All the meetings are supposed to facilitate better communication that is needed in such short intervals/iterations, however I've found wasted time where you're testing a function in the test environment, only to find out later you wasted your afternoon because the developers had already fixed it in the development environment, but it wasn't ready for deployment yet, etc...
Anyway not supposed to be a condemnation of Agile, but it has its issues, and is certainly not infallible or the fix that management might think it is. A flexible waterfall is just as good if not better in many situations. I don't know too many that do a strict waterfall anyway in reality, which is indeed somewhat cumbersome. Agile is the other end of the spectrum and at least in my opinion, just as cumbersome as it's opposite. I think much of these methodologies are a way for management to try to idiot proof or reduce the amount of skill required for any particular project. However reality is, if you get good developers, and good project management, business engagement and documentation, and testers that know what it is they are looking at you will always have better outcomes than less skilled, but following a strict methodology. Bottom line from a management perspective and project costs, methodology is free, and skill costs. However at the end of the day when looking at TCO it might not be, but then again, that might be another project and another manager, call it a success, put it on your resume "AGILE" and move on...
You kind of touched on it, but the big one:
Everyone automatically thinks "newer is automatically better", but it isn't.
There are so many new frameworks and whatnot that you can't kick a rock without exposing a new one from underneath. And those frameworks half about the same lifetime as the insects in my analogy. People are wringing their hands at banks, etc, because they're running out of COBOL developers. But what do we have now? Entire frameworks, languages and services, develop a bunch of hype, only to be abandoned after a few months or years. So now anything based on said frameworks and languages need to either be rewritten, or you need to pay significantly more money trying to find someone still willing to support said thing.
And I'm not even talking fly by night OSS projects, although there are plenty of those. The likes of Microsoft and Google are doing the same thing with entire product offerings. The more new services come and go, the more you realize that you ultimately have to rely on yourself if you want a functioning long term project or service.
If we take "IT" to mean a general IT department, not just any use of computers in a company (i.e., we leave out embedded processors in products, software development where the software is the company's product, etc.) then a few hard truths might be:
There is rarely if ever an easy "one size fits all" answer for corporate IT strategy. If you don't have a senior IT staff that first understands their company's business, second understands the IT strategy in support of the company's business, and third understands how a particular new technology (such as a cloud service) may play a role and can talk about the pros and cons, then you may be doomed to have a chaotic "strategy" where personal power drives decisions and the company's IT solutions depend upon the powerful regardless of whether they are knowledgeable. You may also be doomed to weak and ineffectual management by committees and decisions by default because no one dares to take a stand in favor of what they think is right (and few would understand a cogent argument even if laid out in comic book form).
Everyone in your company can do "IT" (they don't need you to do it for them). Ever since DEC started selling Peripheral Data Processors, then the first "departmental minicomputers" (Data General Nova, DEC PDP 11/70s, VAXen, etc. etc.) emerged on the scene, corporate IT departments have been locked in a tug-of-war over who does "IT". If the corporate IT department wants to be in charge of IT, they have to demonstrate their leadership and competence at delivering IT solutions that the business likes and can use effectively (at least effectively enough that they don't decide to go off and do it on their own).
Change in IT is constant. Just when you think you are done and can rest a bit, something new comes along and you have to figure out what its value is now, what its value will be in a year or two, and how to control the adoption/integration of this new thing into your every changing set of IT solutions.
Although change in IT is a constant, at a high level many things remain the same. The business needs tools that help them do their job (whatever that is). It takes time to achieve new capabilities, but if it takes too long to get the new thing working, the need has changed by the time that you do. Business needs to trust IT, and IT has to respect and support the business. Users are *not* a "test load" on the system, they are the reason why you got to spend a bunch of money on the system in the first place; if you piss them off, you will eventually be in a bad place. Not every bright and shiny new thing will find a place in your environment, but you will have to be able to communicate well with the advocates of each and every one of those bright and shiny new things.
There are probably more "hard truths," but that is a start.
I totally agree, and this is the eternal problem. Employers want instant drop-in replacements for job candidates, and it's totally impossible to do it all anymore. You have to have a focus -- mine has been on systems and end user stuff, and I've been shifting as needed over to Azure stuff, mainly focusing on IaaS. The problem, like you said, is making a wrong bet. My solution has been to learn a lot in my core field and sample from others, being ready to learn as much as needed. You have to choose how you use your valuable time for learning and how far down each rabbit hole you need or want to go.
My real-world example is as follows...I've shifted from end user computing to systems engineering, and a couple years back I started hearing more and more "web developer-y" talk. Web dev is something I just haven't been involved in -- beyond standing up the odd Apache server or putting an app into IIS and tweaking a web.config file. But with the "API economy," and cloud providers using RESTful interfaces to manage resources, I had to get semi-skilled. I had to learn enough about certificates to be dangerous, scripting and PowerShell imprvement, how REST works, some provider-specific syntax stuff, etc...all while keeping my feet in the day to day stuff I was working on. When it came time to start working with Azure, I had to ramp up extremely fast but having at least some clue about "how to learn" everything really helped me out. AWS and Azure and GCP have documentation aimed squarely at "dudebro developers" cranking out JavaScript apps at startups. Coming at it from an infrastructure side means having to learn a few new skills, new vocabulary, etc. before you're truly productive.
I'm not saying it's an easy problem to solve. What I am saying is that keeping your eyes open is important. Learning to spot what's a fad, what's a rehash and what's going to require massive time investment to keep up is important. There's tons of "fear of missing out" especially now that people are starting to call 4 year old technology "legacy". If you let yourself become too narrow-focused an expert on one particular field, it can leave you in a bad position if you miss a key shift.
Stay down in the sewer you filthy clown!
Some settling may occur during posting.
1. This is old, and therefore good.
2. This is new, and therefore better.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
If you've got ten operations employees and ten developers, an you replace them with eight people doing the same work, then that's DevOps.
Ummm, no? I'm the DevOps lead at my company, but we still have an entire staff of developers.
Devops is supposed to be a group that has experience with both production operations and development. You're supposed to involve them in the development process early so they can keep the developers from doing dumb things from an operational point of view and painting themselves into a corner.
I spend my time deploying new infrastructure, managing the monitoring, alerting and metrics collection systems and doing software releases. I also have to educate developers about how to use tools/services properly. I have noticed that people without production experience tend not to be so detail oriented, especially developers with no admin experience. They will totally trash your environments if you let them.
If your processes depend on humans never making a mistake, then they are doomed to failure!
Humans are not infallible beings, they will make mistakes. Your processes need to anticipate those mistakes and be able to recover gracefully from them.
I never understood this. Do this "don't do dumb things" during design, at which point you have many groups involved. Devs should not be making up their own features independently anyway. Having operations look over their shoulder once the plan is put in place and implementation is underway seems like overkill.
Employers want instant drop-in replacements for job candidates, and it's totally impossible to do it all anymore.
I feel like this is the real crux of the problem. Employers simultaneously want someone with broad enough experience across disciplines to be useful in all of them, but *also* expect deep-dive expertise in all of them at the same time or any one of them at any time.
I think this was mostly possible 15 years ago -- you were kind of worthless not understanding switching, networking, server hardware and OS all at the same time to some fairly deep level, and all of it was mostly obtainable.
Now? I only see a couple of those things being understood at deep, expert levels at the same time. I think you can functional in all of them, but not really in expert in any of them.
What's funny is when you get exposed to some of the heavily silo'd people from a place like EMC. Once they start talking about *anything* outside their silo, it's like talking to my dad about technology. I didn't know it was *possible* to be a certified expert in storage systems, yet retain a 1995 level of knowledge about switched networking.
Windows is not secure.
You still have to secure your cloud presence. It's just someone else's computer.
You need to backup your data offsite.
Consultants are not a replacement for people who know your business and can implement solutions tailored to your business.