Software Developers Should Have Sysadmin Experience
blog.professorbeekums.com
blog.professorbeekums.com
Maybe my experience is unusual, but I've never worked anywhere that the sysadmins knew more than the developers about how best to run their code in production. And when things go wrong with it how best to find the cause of the issue.
And I've never thrown code over a wall without having tested it in a representative environment.
The worst sysadmins get in the way of developers. Ones that scale down your CI server to the cheapest, throttled, one the hosting company has, leaving $800/day contract developers waiting for builds that run in 20 seconds on their laptops take nearly an hour. And then try and argue the toss about whether the CI server is cost effective and every few months keep switching it down despite the CTO saying it needs to be left alone.
When a sysadmin sees an issue in "their" environment that they understand there's a tendency for some of them to just see that issue as the only thing the developer has had to deal with that month. In all likelihood, in a productive company, it's the most trivial issue the developer has had to resolve that day.
Often this stuff goes more smoothly where the developers (I mean, it's not as though if you're going to drop one of the two groups of people it's going to be them going) manage production and there aren't people with separate job titles and the resulting friction between them.
Sorry. There must be great sysadmins out there struggling with terrible developers, I'm sure of it. I just haven't seen it.
Sysadmins must deal with interrupts (requests, crises, things driven by external schedules etc) and then in the rest of their time build systems to manage or reduce the interrupts. Developers are expected to produce work on a predictable schedule. This is disrupted by interrupts and obliterates the schedule for proactive work unless your management is very good at making it a priority.
The "prevention of information services" problem is certainly real though. Perhaps it could be addressed by embedding the sysadmins in the dev teams rather than having a department of their own, but then you have to fight org hierarchy.
Having said that, the central assertion is still correct: the absolute best developers I've ever worked with were also top-tier sysadmins (or linux experts, depending on what you want to call it).
The upside that in a three-person IT department there is very little bureaucracy to fight, just the odd "organically grown" legacy system.
I figured the etymology of that word was rather interesting. But yeah, I get the whole SysAd/Dev dual job. They're tough to balance and do effectively. SysAds are firefighters. When the nag(ios) alarm rings, we come a-callin.
Sysadmins, who often manage crises, acquire this experience way or another (e.g, by researching options to fit a square peg in a round hole without leaks), so developers with sysadmin experience tend to all have it. I think though that the key part is the "engineer" part and it can be acquired and used without sysadmin-imposed hassles (interrupts, crises, being underappreciated).
I'm sorry you've had such an awful experience with sysadmin colleagues that you've developed such a corrosive attitude towards them. I've worked in lots of good environments, where dev/ops was being effectively practiced, and sysadmins there were the most effective force multipliers imaginable.
This is going to be a sensitive topic, but can we talk about ""BOFH"" culture somewhere on this thread? (Maybe I'm old and it's now dead, but I think some of it persists)
I kind of understand it as a product of working in an environment where everything is urgent and nothing is appreciated, but when sysadmins come to resent the people they're supposed to be supporting then the force multiplier turns negative. Sysadmins develop strategies for reducing the number of requests at any cost, usually by making the experience as opaque and unhelpful as possible.
The BOfH is the archetype of someone who is excellent both with technology and politics. When you are in a service role, you have two competing priorities. You must deliver people the things they want, but also keep things nice and stable for yourself so you don't go crazy.
An important dynamic in organizations is laziness vs. intimidation. Political savviness allows you to apply intimidation to get the lazy to do what you want. You can threaten to fire, or raise an issue that could possibly get them fired and even if it doesn't, won't make you look good. The BOfH is someone who can respond to political intimidation with adroit technical interventions to ensure that his second priority, ensuring a smoothly-running system, isn't threatened.
If you read the BOfH stories carefully, you see that the operator knows where his bread is buttered and is careful to remain on good terms with the people who really have the power in the company. The whole thing is a phenomenal read on organizational dynamics.
This is sometimes an organizational problem. I worked in a support role at VMware for about 5 years and this is what I observed:
- Support & IT departments typically have enough staff in the beginning
- The organization grows & the department grows to match the new work that exists
- At a certain point, the organizational view of Support & IT/Ops changes, and it's now viewed as a cost that you want to keep down.
- Leaders try to minimize the increases in budget, but the workload per sysadmin/engineer increases.
- The sysadmins/engineers have no control over the flow of new work, which effects the quality of work that gets done and can create a toxic environment.
It literally becomes impossible to handle all the incoming requests. Different people handle it differently. Good sysadmins would learn to prioritize properly, but due to the toxicity some people have trouble handling it so they end up developing strategies to make a certain number of requests "go away".
Anyway- just my two cents.
1) Leadership: Stop viewing the IT/Ops/Support department as a "cost to keep down".
2) Leadership: Treat the department like they are manned by people.
3) Realize that not all requests are created equal. Some take minutes, some take months.
4) Determine a reasonable number of requests/tickets per sysadmin/engineer. Make sure to add padding for things like project work, sick time, vacation, professional development, and so on.
5) Hire proactively to prevent the determined threshold above from being surpassed.
6) From the IT/Ops departments perspective: realize that the incoming requests are coming from people that need your help and they are effectively your clients/customers. Treat them as if customer satisfaction is extremely important!
There are also other strategies where you give a subset of people the ability to work on projects and designate a different subset to be interupted with urgent requests, and rotate the role. There are all kinds of things you can do to improve the situation :)
in such an environment i wouldn't expect any other result. fix the environment, not the rational human response to it.
Software developers, on the other hand, are responsible for making changes. Adding features, pushing fixes, and so forth.
These two points of view are inevitably going to cause friction. Developers are only recently starting to be held responsible for production uptime and the pages that come along with that - and it's a good thing for both sides.
That "most trivial issue" for a developer is something the sysadmin was woken up for 3x in the past, and doesn't want to be woken up for again, so he pushes back. How can he not?
How likely is that the sysadmins were told to 'just make it run cheaper, I don't care' by someone higher in the foodchain?
Having worked in ops for > 10 years, this is how it usually goes.
The SA's job tends to involve a lot of scepticism and caution. You look for problems and try to solve them proactively. One (often easy) way to solve many classes of problems is to throw hardware at them.
Management always pushes back on this tactic. That's reasonable; they need to justify capital expenses (especially if you're self-hosted).
The core issue though is that capital expenses are easy to quantify, while "lost productivity" is much harder to fully account for. If I complain that some hardware upgrade which costs $x could improve productivity, I just don't have hard numbers on my end - it's all napkin math.
In many places reluctance to spend money on infrastructure is also, I think, a symptom of headcount-itis. Managers love to have more employees, and love to have more for them to do, because that makes managers seem more impressive to the org. My manager might have perverse incentives; keeping the SAs busy fighting scaling fires both makes his team look impressive because they're busier, and makes him look better because the capital expenditures are lower.
Obviously, head count is expensive, so this is usually a game of appearances rather than an effective strategy to improve the bottom line. Good insight into productivity is required to catch this kind of stuff, but in the real world I've found that a lot of places just don't have an org structure capable of weighing cost / benefit properly when it comes to infrastructure.
If you're blindly following "orders" to reduce costs and doing things that push up costs elsewhere then you're not doing a good job. A good sysadmin (or the sysadmin's boss) should be able to pull up some numbers and say "Build tasks are being queued for an hour before they run. What impact is that having?", and call a wider meeting that brings together the higher-up-the-foodchain manager, the development team, and anyone else who might be affected. Ideally it'd be the higher up manager who calls that meeting of course, but they may not understand the technical issues.
This is the responsibility of someone above to know whether or not the orders they give should be given. If they need to ask for information from people below them, fantastic, please help them along.
Please don't fall on the sword for incompetent managers.
All it needed was for the question to be asked on the company's internal board and listen to the answer. Even trying it once or twice and I'd probably have forgotten about it in short order. This went on for a couple of years though!
"I will force AV on reads on the developer boxes." "I will install AV on the production DB servers without telling anyone in the development group, then make the developers prove AV was the cause of production slowness before removing it two weeks later." "I will force this crazy group policy on developers and when they complain, I will totally ignore them."
A bad, or uncompromising sysadmin (one in the same) make development work a complete nightmare.
I half believe the reason developers are embracing cloud architecture so much is to remove so many sysadmins out of the equation.
On a side note, a tip for developers. Always make friends with the sysadmins. Buy them lunch or something. Right or wrong, they can make your lives much better or much more miserable.
It was literally true at one of my previous jobs. We couldn't install anything on our own dev machines without approval from Net Ops, not even Notepad++ (I don't think I ever got that installed, never got approval).
We once asked for a new server which mirrored the software of an existing server with two months lead time and got complaints that two months is not enough time to get a new server. I think we ended up getting it in three months, after the new project was supposed to be deployed to it.
Meanwhile we were starting to get into Azure, and we had a new server in Azure up and spinning with everything we needed installed on it in about 15 minutes.
The Lead Developer said, "We need to get as much stuff on the cloud as we can so we can stop dealing with this mess." We dealt with a lot of PHI there, though, so there was only so much we could do.
Couldn't this argument be applied to any developer for any discipline/speciality?
Sure, more knowledge/context is always better if reasonable to attain, but my experience suggests that your above concerns could also be addressed via team organization rather than expecting all developers to know all things.
I was a sysadmin with various ISPs in various countries for 15 years before I "turned to the dark side". I'd been using Ruby for a few years with Puppet and Chef, and after dealing with one too many "flaky coders", I picked it up.
I have to say, coding is far more enjoyable, though both come in handy in my day-to-day life.
It sounds like you've dealt with a few "BOFH" sysadmins. Don't worry, we're not all like that, and those that have been on both sides of the team will probably see your way.
Tell your boss I'm available (remotely), by the way ;)
D: I have noticed that task Frobnicate has not been running in Production for a month, then checked and it is not even added to scheduler!
SA: There is no mention of Frobnicate in the pipeline for scheduled tasks.
D: What pipeline? FancyPancyScheduler is bundled with application and tasks are defined in DB, I have done it in Staging and everything worked, Frobnicate is all the fuss in the team, you must have heard about it, why don't you check for changes in Staging?
SA: We have well defined pipeline to manage scheduled tasks, currently the executing agent is Cron, not FancyPancyScheduler.
---------------------
Developers and Admins have more or less the same goals (stable, maintainable and extensible), but on different pieces of the system (code vs infrastructure). In my short career I have seen problems arise where one party makes plans and changes according to current or even past (it worked like this earlier) state of the other party. This applies to both developers and admins.
So I sort of agree with your sentiment, that developers need understanding of system administration. Though, depending on team size, I believe it is entirely sufficient to have someone in Developement who understands system administration and actual infrastructure, and someone in Operations who understands developement and actual stack. This is where I hope DevOps will end up at: arbitration between Developement and Operations to ensure smooth sailing forwards. Because the debate "I will do it in code" versus "this must be done on the edge" (e.g. static assets in a website. Served by application or web frontend?) will never be resolved.
Edit: formatting
I disagree because this generalizes both developers and admins too much for my own comfort. I've seen sysadmins get really sloppy in the name of getting something into production quickly out of hubris without thinking about the full lifecycle of an application (common with developer-turned-sysadmin engineers - I am one and tend to be more reckless due to the reality that most of the errors I've observed would not have been caught going super slow - that adding more test code does not necessarily find the most critical of errors, just increases confidence) and especially in enterprise software most developers are sitting on features and are nearly allergic to new trends by their organizations valuing revenue loss far above losing growth opportunities.
Of course the stereotype is that operations wants things stable and manageable at the behest of business while developers want to deploy new stuff faster (because the idea of development in most places is to create something new). Modern infrastructure becomes increasingly code-driven and emergent as opposed to manually formed and restrictively managed sysadmins will have more room for errors that may change this into the future. Meanwhile, developers are increasingly under greater scrutiny by society when rolling out features such that nobody can ignore the concerns and they may be eventually forced into nearly waterfall-like development patterns. We can already observe this with the infection of Agile with enterprise bureaucracy / overmanagement back into the rest of the software industry as many of the former smaller, agile tech companies become big behemoths themselves.
this is the weirdest part of the whole devops mantra. like, I know how to evaluate the complexity and memory requirement of code way before I write it and I guess most compsci should be able to do the same.
so either it's yet one more attempt in getting cheap labor into workable territory or plenty people where this myth originated are being cheated out of their money for a graduated curriculum that teaches nothing of value.
Those are only tiny slices of real production bugs. No amount of complexity analysis of your code ahead of time is going to protect you from all of the issues that arise with integrating any large system dealing with lots of requests. You run into all kinds of things like query optimization, kernel TCP tuning, load balancer problems, cache thrashing, high latency clients, out of spec clients, power failures, etc.
If you think knowing the theoretical behavior of your program in an ideal environment is enough, you are exactly the type that throws code over a wall without having tested it.
sure if you bounce them all up like that it might look like you have a point, except it falls apart when you attribute concerns properly.
or please explain, how would dealing with kernel tcp tuning part-time help Joe Random developer write better code?
Many devs out there who work with Windows or do mostly front end often have little experience in that domain.
Seeing alot of work get done at uni by students - who also actually some backend (friend did a blockchain project recently) did infact do very little backend discovery - the job was delegated to another student to get the env. Up and running.
I've had the exact opposite experience. In most of the organizations I've worked in the "sysadmins" (mostly Systems Engineers/Operations Engineers actually) were stronger developers than the people who were actually developing the software. But that could just be a title shift, because what I've seen happen is that people who care about systems but have a development background gravitate towards operations roles and end up filling in as the "actually Senior" developer for the dev teams.
In the 15 years I've been doing this, I've only occasionally met someone who has stuck hard to the development side of the house but actually is competent when it comes to systems. Most developers have zero care about any of the lower level things like networks, hardware, and even backend software/databases which are required for their application to succeed. A common scenario is that the devs choose an inappropriate backend stack because they chose the easiest things to deploy rather than what is best suited for the use case. Then when things blow up, they beg for an ops team to be created, which usually starts by hiring people who are competent enough developers they can relatively painlessly replace the entire backend with something sane (e.g. Mongo to Postgres shifts are commonplace, because Mongo is a dog in the real world).
> The worst sysadmins get in the way of developers. Ones that scale down your CI server to the cheapest, throttled, one the hosting company has, leaving $800/day contract developers waiting for builds that run in 20 seconds on their laptops take nearly an hour. And then try and argue the toss about whether the CI server is cost effective and every few months keep switching it down despite the CTO saying it needs to be left alone.
Yeah, that does sound terrible. I agree. My top 5 jobs as a systems person is the following in priority order:
1. Make sure production stays up for our customers so we keep making money. (5 9s targets)
2. Ensure the security (and compliance) of our systems so we don't get hacked and we maintain customer expectations about compliance.
3. Ensure the performance of our product/systems is up to customer expectations.
4. Make sure deployment automation is solid and streamlined so that deployments are frictionless
5. Make sure new code is actually being deployed regularly and remove impediments to deployment so customers get features faster.
You'll notice a trend here I'm sure. The most important thing is the customer, then the developer. The biggest frictions I've seen between systems/development teams is when the development team believes that their desires/needs are the highest priority. The systems team is /not/ there to be at the beck and call of the development team, it's to be at the beck and call of the customer who is paying the company money. As much as possible I try to ensure the development team is having a frictionless experience, but if something will negatively impact the customer it is 100% my job to throw a roadblock in the way of the development team to prevent that. The customer of the company is my priority, and everything else is secondary.
It is an interesting exercise to generalize this statement in context of general engineering.
It seems either your conclusion is held to be incorrect, or, we reach the conclusion that software development is not engineering.
This is not personal criticism but you know how I know you're not working in a highly regulated environment? Check out the Carnegie Mellon Capability and Maturity Model (CMM) as a counterexample of where some companies go. Development is not at one remove but two from production support. There's an "operate" team between them and production environments and in a regulated environment operate doesn't have privileged access either. That'll be a third team due to separation of duties requirements.
Now imagine you're paged out to a call where your code is slow or failing and you're not even allowed to login to where the issue's happening. Fun, right?
This is why I'm absolutely loving the devops changes we're seeing now - because developers can control the environment without retaining control of it. My ideal is to apply some sensible defaults (no, you can't have all my crashdump space for your app logging; ask for more disk instead, no you can't run ghost/glibc/pooodle vulnerable versions of libraries) and otherwise let the developers spec the OS as a template or dependency for their app. It's much better for me since if I'm required to troubleshoot I know my requirements are met and otherwise the developer may do as they wish. Everyone wins and my control requirements are satisfied because remember developers are never allowed production access in regulated environments.
>Maybe my experience is unusual, but I've never worked anywhere that the sysadmins knew more than the developers about how best to run their code in production. And when things go wrong with it how best to find the cause of the issue.
I guess it depends on what you mean? The developer is in the best position to know what logging there is and how to enable or it increase verbosity. But they may be completely ignorant of how the operating system's tcp stack, memory management or other mechanisms work. Have you ever had to explain to someone that a java out of memory error had nothing do with the fact that linux is using otherwise idle memory to buffer i/o and that they're misreading top output? That the actual issue is their object management and just increasing the JVM's heap size is at best a bandaid?
If you have a developer who insists every issue is the operating system, sometimes the SA has to know how to dig in and run stack traces, probe tools (systrace, dtrace, whatever), jmx queries, etc until they can pinpoint the offending code.
As another example if you have an application that isn't draining queues quickly enough and therefore sending back tcp zero window frames upstream, what's the solution? A hypothetical lazy developer will say "it's the OS not queuing enough data, increase the OS buffers." A hypothetical lazy SA may say "it's the app not consuming packets quickly enough, rewrite the app."
In reality if we've all been paged to a priority one bridge the solution will probably be the combination of the two - tactical fix of increasing buffers to create some time for development to understand why the code isn't doing what it should and fix it.
When even the US military - one of the world's foremost investors in management and leadership research - has largely abandoned command and control (the military equivalent of Taylorism) we really need to ask whether structures that enforce a management/worker caste vs. one that empowers those closest to a problem are effective beyond any meaningful scale.
Even so my original point remains - in some kinds of highly regulated shops there's enough external pressure for controls and separation of duties that the developer simply cannot have access to production. I'm not defending either practice (CMMI or seperation of duties), I'm just saying in some places it's reality, regardless of perceived drawbacks or overhead.
I've not seen a professional developer be confused about Linux using otherwise idle memory to buffer, no. I have seen that with sysadmins who mostly look after Windows boxes and were somewhat unfairly dropped in at the deep end.
I've seen JVM heap OOM errors be caused by both object management issues and applications that would legitimately benefit from larger heap sizes. Many, many times.
I think I'd fall off my seat if I saw a sysadmin use JMX to find an issue. I did see a security guy (so not really a sysadmin, but he was doing a related job) use strace once. He was remarkable enough to have his own Wikipedia page.
Is there somewhere to read about this, I this might have come up with one of our projects. (At the time, from googling, I suggested they try mark and sweep - I didn't really have any idea but was of the opinion they had lots of small objects.) I don't have much experience in Java but was trying to be helpful!
I think you've just described me. And I don't see the argument against sysadmin.
> leaving $800/day contract developers waiting for builds that run in 20 seconds on their laptops take nearly an hour.
Sorry I just can't take you seriously.
When I switched companies, I came across better developers. Some had decent sysadmin skills, but the main difference was that they actually took interest in how things worked past the 'git push', and when I asked / required them to make some changes that would make my life easier, they listened, discussed and adopted when appropriate. With those same guys, I took interest in what they were doing, what their actual job was and came up with ideas that would make things easyier and run smoothly on both ends. After a while I figured out that they weren't actually better developers - they were better people. (Also, I figured out that being grumpy was not the best approach and that patience, kindness and gratitude could get people to do more than snark, humiliation and flame-throwers.)
I guess my point is: you don't really NEED to have sysadmin skills to be a decent developer; what you really need is to care about what sysadmins do - be curious, talk with them and trust them when they say that your brilliant idea won't work in production.
I've seen this ignorance even in college professors. In my first programming class in college I took a CS class that had both CS and IT students in it since it was required for both kinds of students. The (CS) professor kept trying to convince students how much better CS was and gave some good arguments (ie: salary) but the most arrogant thing he said is that IT is a subset of CS and that by doing a CS degree you would understand everything it takes to be in IT. He also mentioned how in IT you would be constantly fixing other people's computer problems but as a software engineer you wouldn't need IT's help since you can fix it yourself. The funny part is part-way through my degree I realized that college didn't even offer a real CS degree it was called "CIT with Computer Science Emphasis" which none of my advisers nor professors mentioned would cause issues getting jobs outside of Utah, the best thing I did was leave that school and finish my CS degree elsewhere which caused me to lose a lot of unnecessary credits and almost felt like I was starting over. I feel like I got scammed but that's beside the point I am yet to work for a company where a software engineer gets to manage his own computer without following IT guidelines like my CS prof had described.
I didn't realize the importance of all the "admin stuff", before the our newly hired sysadmin came to me and asked if I could help him figure out how to deploy the project I was working on. This ended up being a looong chat about monitoring, redundancy, architecture, security... you name it. What I've always thought of as installing and configuring software turned out to also touch designing the software so that it works reliably and is easy to maintain.
I don't think I'll ever have plenty of sysadmin skills, but knowing even the general idea of what's important to sysadmins helps a lot. Also, being able to become another interruption in their day and consult ideas is priceless. :)
That's an individual skill as well as a systemic one, though.
Either way, this is a two-way street. And often times the culture of one group or the other gets in the way. Which is really unfortunate.
Having been an admin myself, gradually moving more and more towards development, I understand what things in software are annoying for an admin to have to deal with. Most developers simply don't care. Grant full permissions or don't expect anything to work. Any objections and you're a troublemaker. A better attitude would have gone a long way, but firsthand experience works best.
In addition, it helps me greatly when there is no (decent) admin around. I know whether to suspect the software or the system it's running on, how to keep things running on a less than ideally configured/maintained system without completely compromising security, can help users when the problem they're having is not a problem with the software, but a problem to them anyway – they love the extra mile – et cetera.
It must be said that some admins are just as shortsighted. Knowing what kind of measures actually work for stability, security, and so on, I've come to strongly dislike those who only complicate the situation to no benefit, as well as those who point their finger at the software when it really is their system that's causing problems.
I say this because if I had to wait for a sysadmin every time I wanted to see if something worked, I'd spend a lot of time doing nothing. And it's likely that I couldn't even solve a lot of problems.
So I think you not only have to know what they do, but some of how to do it.
Why do things like Docker exist? Because developers got tired of sysadmins saying "sorry, you can't upgrade Ruby in the middle of this project". Why does virtualenv exist? A similar reason.
Containerized ecosystems (which is to say basically all of them now) are really a sign of those of us on the sysadmin side of the aisle capitulating and saying that developers can't be stopped from having the newest version of things, and I think that's a bad idea.
15 years ago, when a project would kick-off, as a sysadmin I'd be invited in and the developers and I would hash out what versions of each language and library involved the project would use. This worked well with Perl; once the stacks started gravitating to Ruby and Python it was a dismal failure.
Why? Because those two ecosystems release like hummingbirds off of their ritalin. Take the release history for pip[1] (and I'm not calling pip out as particularly bad; I'm calling pip out as particularly average, which is the problem): in the year 2015, pip went from version 1.5.6 to 8.1.1 (!) through 24 version bumps, introducing thirteen (documented) backwards incompatibilities. Furthermore, there were more regression fixes from previous bumps than feature additions. You'll also notice that none of these releases are tagged "-rc1", etc., though the fact that regressions were fixed in a new bump the next day means they were release candidates rather than releases. Ruby is just as bad; the famous (and I've experienced this) example is that an in-depth tutorial can be obsoleted in the two weeks it takes you to work through it.
Devs are chasing a moving target, and devs who haven't been sysadmins may have trouble seeing why that's a bad idea.
Those technologies don't exist so Developers can get around Sys Admins and ignore your helpful advice. They exist to solve that problem that makes the Sys Admins role there necessary. It removes the underlying need for a Sys Admin to worry about the versions. Admins should see this as a good thing, but in my experience many dislike it because it takes them out of their Gatekeeper role. We shouldn't WANT to stop the Developers from from having the newest version of things. They aren't kids playing with toys that we need to nanny over, they're doing work that creates values and the fewer things we do to get in the way of that, the better.
If something breaks due to version changes, their testing should catch it. If things are breaking in production, we ought to get involved because there's some other problem, but before that we, as a profession, need to learn to get out of the way and let people work by letting technology handle the problems. The "Gatekeeper" mentality needs to die as quickly as it possibly can.
In my experience (university), yes they are, and they should do that at home.
Why do you need the latest bleeding versions in the first place?
In my sysadmin experience, people believe software gets bad and deprecated as soon as the glory next breaking version appears. I don't think I need to argue why this is an illogical stance.
With my developers hat on, bumping to the next version mid-process reliably introduces more friction than is worth it. People think the next version solves that one weird issue but ignore that it introduces two new ones and that the software must be changed to fix five new incompatibilities.
But the solution reliably is to just not use that weird feature that caused the bug in the first place, and think what a clean solution would have been. And guess what, the result is a cleaner and more compatible code base. It's a tip that works for me again and again: If there is friction, think - before spending the next hours with an update that will soon lead to new problems.
It's great that you can for example compile Linux without too much friction. It's great that arcane shell scripts can run on any system. Stability (in a compatibility sense) is not a nice-to-have, it's basic sanity.
Stability, sanity, all that is amazing, and a must have.
But also bug-fixes, security improvements, and performance improvements are wonderful too, which tends to come with using up-to-date dependencies.
The problem with the latter, as you mentioned, is when it introduces breaking API changes and is wholly not backwards compatible. This is not a "kids playing with toys wanting to experiment problem" this is a bad software problem, which is why I like Go, and why I liked Java when I was doing it full time. If the language you use has backwards compatibility as a first-class citizen, most likely the package authors will act that way too, and then the maintainers, and eventually the developers. Limit your software choices to those who care about not breaking everyone's shit every 2 weeks. Heck even when I write my own API's now that I know only my company is going to use internally I am thinking about this.
I don't particularly care about having my software on the latest version. I personally prefer using the old version for six months while the newest version gets the bugs worked out of it.
I know sysadmins value reliability and security, but it's really frustrating when every upgrade takes dozens of hours of work to approve. Questions like "What features do you need in the new version" miss the point. It isn't about the features of the software, it is about maintaining a modern code base.
Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later.
Ultimately, sticking with a version of software because it works is trading a little stability now for an absolute mess down the line.
Because the newest version has several features that we would like to take advantage of immediately?
Look at PHP 7.0 which introduced return types, and 7.1 which introduced nullable return types. These are features I really want in my application, so we upgrade.
The sysadmin role has traditionally been a focus in that environment (e.g. controlling access to cluster resources).
Well - that's all well and good, when put such that "Gatekeepers" are viewed as blockers.
However, we "Gatekeepers" are the ones that get paged and / or yelled at by a CTO when an application keels over. Not the developers. The developers get to sit in their sandbox (otherwise known as "production" in 2016/17) of ever-changing library versions that were only rapidly tested in QA. Then they play a game of Starcraft II, scan HN and go to bed. When something runs out of memory or crashes in the middle of the night, we get paged. So, hell yes we should be involved in the process.
Sincerely,
Gatekeeper
When I started at my current company the traditional silo between dev and systems was there (although we were allowed to deploy our own stuff) - they managed everything we ran our apps on and we just deployed them to servers they had already configured. Over the past ~3 years we've made a lot of changes, the department manager for our IS team is present in our daily standup calls to relay information between our two teams and we now have a couple separate VMWare clusters dedicated to our applications and VM running on them is our responsibility for the most part. We are the first to get called for issues with our applications, and where necessary we work collaboratively with our systems team to resolve them - we don't throw blame around, it does no good.
I should add most of this is only possible because we have real DevOps people on our team (well, really, it's just me right now - we lost our other and need to hire a replacement still) - not developers who know enough to copy a blob of crap to a server to run, but people who have real skills in both aspects. We are trusted to maintain things because we can do it right, and while it took a lot of work (and some unfortunate infighting) to get to this point both of our departments are working great with this arrangement.
There's still kinks that need ironing, we've not done an adequate job at writing documentation so our systems team can help with some failures (primarily on our Linux VM's, our whole systems team is Windows admins) if we aren't available - but it's on the radar as well as getting PagerDuty set up to escalate alerts to them if we don't respond in time (like having our PostgreSQL data volume fill up over the weekend, not a call I wanted to get at 10AM on Sunday).
So yeah, fix your culture issue, get people communicating daily between your teams, share responsibility for issues instead of placing blame.
And that's why people are moving away from that model. It's part of the reason DevOps is being embraced as a model. Developers should be on call to support the applications they build. You get benefits all around.
This is institutional failure.
No, they really don't: they remove the ability of system administrators to administer versions of software across the total system.
This is bad, e.g. when a new OpenSSL vulnerability comes out (it being a day ending in -y) and every piece of software has to be updated.
> We shouldn't WANT to stop the Developers from from having the newest version of things. They aren't kids playing with toys that we need to nanny over, they're doing work that creates values and the fewer things we do to get in the way of that, the better.
I am a developer, and I disagree. We are, by and large, kids playing rather than adults making carefully considered decisions. We'd rather use v3.0.rc-1-awesome rather than 2.17.12, because the former is the version that adds an API that saves us from writing twenty lines of code, never mind that it also is untested, unstable and very likely insecure.
We need adult supervision. We need oversight. That's why I argue for using stable, LTS-style distributions, and running against the distro packages unless there is a very good business reason not to (and yes, 'we can't implement necessary functionality in a cost-effective timeframe' is a valid business reason). I'm not opposed to using the bleeding edge when it makes business sense; I'm opposed to developers using the bleeding edge because they like it, and keeping the business in the dark.
From an architectural point of view, microservices take the reductionist approach to system design to an absurd limit, and per my professional experience (fwiw & ymmv) are due to the general architectural illiteracy of the rank and file practitioners in this field.
After reading your comment it now occurs to me that Docker and other container systems are actually a huge organizational tool. One issue I have encountered at companies is keeping the IT and development departments on the same high level organizational incentives to keep political barriers from coming up between them (and conflicts arising).
Containers can help keep everyone's incentives aligned because System admins can focus on the actual administration aspects of the systems and infrastructure (that devs do not need to be concerned about, like vnet layouts and whatnot) while devs can focus on the actual development and deployment without having to have everything confirmed and approved by the IT departments.
(I have been both the sysadmin saying "no" and the developer mad at sysadmins saying "no". But going slower and doing our homework has never, ever hurt me or my employers.)
Developers may not be as aware of those topics as sysadmins.
I've worked at a place where they were running PHP 4.4.9 until about 8 months ago. And they were upgrading to 5.4! I get that it was work to convert a lot of the older code base to 5.4, but it was already passed EOL when they were switching to it. And 5.5 wasn't much behind it.
So now in the near future, they'll need to upgrade again (though they probably wont), and they'll probably jump to 5.6, which EOLs in two years (probably two years after it EOLs).
I have regression tests to catch if an upgrade breaks anyyhing. What does a sysadmin have to approve or deny an upgrade? A little beard stroking and changelog reading?
I think the movement towards containers is like you said, to keep sysadmins off the code. Sysadmins add value in setting up the infastructure and keeping it running. They subtract value when they want to tell developers what version of a library to use.
Because he maintains that installation and you don't? But, yeah, that's why virtualenv, Docker, etc. were invented, because devs kept getting sick of installations having consequences.
What does a sysadmin have to approve or deny an upgrade?
Check for conflicts of this version of this library with other software currently in use (by other developers maybe, or even by the same developer). Add it to the watchlist on the dozen or so security mailing lists and newsfeeds he checks daily. Read the changelog and look for implementation problems. Read fora and look for performance problems people are reporting. Yes, beards get stroked during this process, but time and again we see that developers refuse to do this, and wind up coming to us when they break something because of that...
Because a Python sysadmin has been through all the transitions of packaging systems, all the nasty corners of "backwards compatible" changes, and knows how underlying changes to the operating system will affect your code, what the storage behaves like under load, and why one tech is not "better" than another. If you really hired an admin (cough, "reliability engineer") for a Python codebase that doesn't know Python, well, that's a different question altogether.
> I have regression tests to catch if an upgrade breaks anyyhing
You don't know what you don't know.
When you can reason about the multiple ways the above statement can fail, congratulations! You are now a seasoned sysadmin, the scorn of junior developers who just want to get things done (who incidentally read a great blog post the other day about a new packaging system that we should immediately transition to and by the way it's all backwards compatible).
Minimize your dependencies. It's incidentally also what leads to clean code bases.
I've had this problem over and over again (biggest one last being with the US Census). Folks insisted on upgrading a python library and auth to the hosts stopped working.
What if the sysadmin can code in the same language as you, faster and with less bugs?
> 15 years ago, when a project would kick-off, as a sysadmin
> I'd be invited in and the developers and I would hash out
> what versions of each language and library involved the
> project would use
(As for software that releases often, maybe it's an over-correction, but there's a reason things don't work as they did in the glory days, and that's because they were never really that glorious.)
This doesn't necessarily rule out the expertise of systems administration, because the platforms for all of this need to be built & maintained, and there's still a lot of work to be done on network boarder security, etc. It's a movement that focuses systems administration to systems administration, instead of having to be this big org arbiter of microdecisions, and all the baggage that goes along with trying to be the gatekeeper of all.
Because that's how software developers wrote every dominant packaging system :P
There are tradeoffs to self-contained units. Disk space isn't so much of a practical concern these days, but security is very real: with a dozen apps, you could be at the mercy of a dozen different entities to update their embedded OpenSSL libraries.
Devs come from a mindset to actively create change. This is to add new features and deliver new value and product to the business. As a Dev I do have to say that many Devs don't have enough experience in operations to understand properly how to help sysadmins, many don't understand the complexities of that job.
These two perspectives are at odds, and they should be. The new tools, like docker, start giving everyone what they want... Devs pick their dependencies, and in theory, can't stomp on the sysadmins pristine environment.
To respond directly to your question: because there are new things available in new libraries that allow us to develop new features!
If developers want to use newer stuff usually they have a good reason. The ability to hack around the deficiencies of old dependencies does not mean that one couldn't get a better, cheaper solution with newer technology.
If you run into a bug or problem with a 3rd party component (open source library, commercial tool, whatever), one of the first things they are going to ask you to do is upgrade. The fact you're on an old version of some library is an easy (and sometimes correct) scapegoat for problems.
Put yourself in the 3rd party's shoes: if you spend a bunch of time trying to fix a problem that turns out to be a bug in a separate library that's already been fixed, that's entirely wasted time.
The same goes for direct usage: you're likely to spend time fixing problems that have already been fixed.
The reason why virtualenv exists is because different apps may have conflicting requirements, and you have apps that need to be deployed in different environments with different versions of different libraries. I know that even if I were developing against versions of libraries in system packages, I'd still end up having to use virtualenv in development (EDIT: I wrote 'production' here by accident) because my stuff gets deployed on different versions of Debian and RHEL, necessitating virtual environments if only so that I can make my development environment as close to production as possible.
> In the year 2015, pip went from version 1.5.6 to 8.1.1 (!) through 24 version bumps, introducing thirteen (documented) backwards incompatibilities.
Much of that has been down to efforts in recent years to finally fix the major issues with Python packaging. It has settled down quite a bit. Also, the 1.* to 8.* change is because the initial '1' was dropped: 8.* is essentially 1.8.* in the old versioning scheme.
I'm not saying that this couldn't have been handled better, but it's not just a 'hummingbirds off of their ritalin' situation: Python spent many years with packaging stagnated, and what you're seeing is rapid development to fix the mess that years of PJE-related neglect caused.
As a Ruby developer, I can only laugh at this particular example. No Ruby project I've ever worked on ever upgraded their gems midway through a project, much less the version of Ruby. Developing procedures for this kind of ongoing maintenance is just way too much to ask.
This stuff tends to get done years after the original devs have all moved on. Maybe they tried that kind of thing back in the early days, before I started working with Ruby, definitely not today.
Yep, that sounds like that 'long time ago' I was talking about. Nowadays you can do that, no sysadmin to tell you not to, but nobody bothers.
One had to read MSDN every day to keep up with what might break on sites you had no control over.
> in the year 2015, pip went from version 1.5.6 to 8.1.1
The only releases in 2015 were 6.x and 7.x.
There were 8 documented backwards incompatibilities, 4 deprecated the previous year, and 3 documenting a couple bugs that were fixed several days after the 7.0.0 release.
These are the sorts of thing an aware Python developer will know.
We may be counting regressions differently; I'm including both adding and removing the spinner as a regression, for instance (since both the addition and removal added unexpected behavior).
Note that the undeniable regressions that occurred in releases during those 15 months included:
1. Exceptions raised in any command on Windows
2. Switching from not installing standard libraries to installing them back to not installing them
3. Blocking if the particular server pypi.python.org was down
4. An infinite loop on filesystems that do not allow hard links
Note that in that time they also added yet another internal package management system (incompatible with the existing two), changed the versioning semantics twice, and dropped support for versions of python that were 3 years old at that point.
And, again, there's nothing particularly wrong with or bad about pip; this is just what a younger generation of developers are used to.
Releasing an RC often results in nobody using it and hence not finding the bug even in several weeks, but it gets caught almost instantly in a release… At least, that's my experience in shipping various RCs that have led to next-day regression-fixes once it does ship.
While yes, better testing would solve such issues, but at some point the line has to be drawn as "good enough", because there's ultimately a limit to what is reasonable.
For development as a whole it is really great though in my opinion.
Or you simply use something like this: https://bazel.build/
The "backwards compatibility" philosophy isn't so explicit for the ecosystem, mostly the language? Is the test-on-install-by-default making a big difference there?
I also think the widespread use of VPSs rather than accounts on shared servers (again, containerization) was a factor. In the 90s and early 2000s, you usually (even in a corporate setting) had an unprivileged account on a server with a given version of apache and perl, your own cgi-bin directory, and possibly some latitude on a personal CPAN install directory. The lack of containerization meant you had to compromise between using newer software and breaking existing use cases.
So I guess I think it's not so much about Python vs. Perl per se but about the technologies available when those languages became popular among developers.
That said, I haven't had any more problems with PyPi packages than I did in the past with CPAN. Yes, pip always wants to upgrade itself, but that sort of every-damn-day software upgrade cycle seems to have become quite prevalent, not just in the Python world.
I have been involved as a consultant in large software projects in the last two years and a vast majority of money lost in delays and bugs was caused by devs not understanding: 1) the difference between virtual memory and physical memory 2) the difference between costs of data storage per storage medium 3) the concepts of network round-trips 4) and hardware bandwidths 5) how to install and configure a web server on a workstation 6) how DNS works 7) how AD authentication works 8) what ORM frameworks do 9) how to write a raw database query (not necessarily sql) 10) the difference between navigating through database records on a database server vs. an application server vs. a client, 11) HOW TO INSTALL THEIR OWN WORKSTATION AND TROUBLESHOOT IT!!! N) etc. and those are just the topics that I can immediately remember.
As I see it, it's not about "they should". For me it's about understanding how many devs deal with such a level of ignorance on the systems they interact with, on a daily basis. This situation hurt my feelings everytime it happened and I struggled to accept it. I am not a sysadmin nor a developer but my daily work is insanely improved by my (even basic) understanding of how my workstation works and how to manage it.
Would you trust a RF engineer who couldn't troubleshoot his own radio designs? why would you troubleshoot a software engineer who can't troubleshoot his own software as deployed in a real world environment?
Looking at it short term a well paid developer troubleshooting all issues on their work laptop could be seen as a waste of resources but for me software development is a beautiful craft. I also wouldn't trust a carpenter who can't obsess over wood or tools. If I overhear two developers comparing notes on their tmux setup somewhere I mentally upgrade them into the interesting category right away.
Last time I tried, half of the download links were absolutely non-functional. Their documentation didn't help much, either, since they pointed to the non-functioning links. I got a lot of shit for that one, but felt completely vindicated when it happened to someone else a year later.
It takes a while but I've never found it to be a pain in the butt and I've used it, off and on, since version 6 in the late 90s.
If the install errors out it gives you an error message, you google for it, figure out what the problem is (most common messages are easy to find solutions for), fix the problem, reinstall, done.
I remember on the first day of a new job being given a folder containing all the MSDN subscription disks in the mid-2000s and being told to install visual studio.
I'd only ever used notepad as an editor before.
This is a massive stack of DVDs with multiple disks, but worse there are a bunch of cds listing different versions of a thing called "visual studio".
After 15 minutes of struggling and surreptitious googling because I didn't want to look stupid on my new job, a colleague walked by, went "oh", picked out the right disk and said "that's the one you need". And I had to do the same for multiple new starters.
Even today when you have to install something from MSDN, you search for "Office" and get a bunch of irrelevant language packs listed at the top which is definitely not what you want, then also have to know what x86 and x64 means, something a novice will not know, and know what "SP" means and that "SP2" is better than "SP1".
After all--we're all developers. Automate!
Of your 11 points, I understand 1-10 quite well, but I'm not great at 11.
I think the skill sets are quite different, despite the fact that a lot of people have both. I was never really that "into computers", but I have a burning passion for building large software systems fast and well.
Metaphor: I love to travel to exotic locations across the planet. That doesn't mean I'm also interested in building airplane engines.
To be clear, I'm not bragging. It would be great if I was good at this stuff.
I've not had them myself, but I have talked to other sysadmins who've had devs that couldn't install their own IDE. These people weren't seniors, admittedly, but they were still drawing pay...
For my defense (I'm a dev), OSes don't make it clear. Mac OS becomes extremely slow when I load a big virtual machine and yet displays "Swap 450Kb, 500Mb RAM free". Or with a sole text editor open after a long session it may say "Swap 750Mb". In both cases my logic tells me the swap and free memory should display the opposite, so I can't match my knowledge with the OS behaviour. Then comes Java which adds another layer of memory limitations.
> how many devs deal with such a level of ignorance
I can talk because I was 4 years ignorant, then met the right teams. It's impossible to learn and gain trust in your learnings if you start ignorant, and ignorant devs know it. We constantly need help and don't understand how ticking a weird checkbox in Eclipse makes the compilation different: Without directly executing the original command line, you can't learn anything, and architects in those kinds of companies give you too many proxy tools ("SDK") that you can't improve. You're on an old 14" screen anyway. Also, Windows is so inconsistent and weird that you just assume sysadmin is for people from another planet. My skills only took off 4 years later when I installed Linux, then Mac, and was thrown in open-source libs. It was so easy, in retrospect, and I'm so happy having been in the right context.
Udacity has a pretty good OS summary course. I had personally forgotten what a TLB was until I watched watched it.
yes, however there are items that are more important (ACLs, AD, Security, OID ... etc) that are a little more important than the new shiny JS framework.
I'd rather burn brain cells learning Haskell than trying to understand why so much effort is being spent on JS.
1) Building the wrong piece of software/end-users not having enough influence on what get's built.
2) Lack of delegation, having people make technological/feature decisions about a product they only spend 5% of their time thinking about.
3) Organizational incentives not aligned correctly.
4) Not following software engineering principles that were discovered in the 70's(they also don't follow any software engineering principles discovered since then, but I'll give them a pass)
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." — Robert Heinlein, Time Enough for Love
I've work with many of them, very good about Adobe products and Apple last thing, but clueless about, why their final code is of poor quality.
Fortunately, many of them did get their Ego down, when the web did start to move from markup (html+css) to code (js). Until then, they did take any feedback from a sysadmin, as an attack to their work.
About developers and architects... they should simply be the final support (24/7 calls included) for their work and changes.
As a side note... a sysadmin IS A developer (a systems developer). An application developer, usually should be a systems developer if he/she is working in a project that includes a platform to run (unless he/she is just uploading an app to any appstore). An operator with limited privileges, is just that. The concept of "pure developer" or "pure sysadmin" is so 199x...
This is why Ilya Grigorik's book, High Performance Browser Networking, exists. It's a great reference to that end as well.
But then you need to understand the differences between HTTP 1.1 and 2.0 and how it handles multiple requests from the same page. 1.1, you would probably be better off with a single concatenated file, 2.0, perhaps several. And then what about compression? Any good UI developer should be considering compression of that file, cache control, etc.
I see too many front end developers shy away from this stuff and create bloated monstrosities. They feel it's someone else's job... but if not the UI developer, then who??
Well, indeed, the higher level protocols, like HTTP, DNS, etc, are more useful on a daily basis.
How you get there is up to you. My own path was freakishly meandering. Don't be afraid to get out of your depth, but try to have a mentor around to stop you drowning.
And remember that DevOps is a mindset, not a job. If someone tries to setup a "devops team", run away.
Same here, though I was aided by being able to be really confident about stuff when people came calling with the checkbook and a quick study once I'd landed a gig. I learned to do what we would now call "sysadmin stuff" (manual administration of hardware) as a kid because I broke my Linux machines a lot. Then I went into the web development gristmill for a while. Ended up leading a multi-platform mobile team with zero mobile experience because "you're a good developer, you'll pick it up" (I did); I literally went into a devops role knowing no Ruby (to say nothing of Chef) under pretty much the same rationale.
"Fake it till you make it" is real, but then you gotta make it. ;)
Therein lies the best career advice I could possibly dispense: just DO things. Chase after the things that interest you and make you happy. Stop acting like you have a set path, because you don't. No one does. You shouldn't be trying to check off the boxes of life; they aren't real and they were created by other people, not you. There is no explicit path I'm following, and I'm not walking in anyone else's footsteps. I'm making it up as I go. - Charlie Hoehn
I've worked with developers who fully understand the systems they are deploying on, and developers who develop for an abstraction of services rather than a real world environment - I tend to prefer the former to the later because the deployment process is much less taxing, even though the later tend to have better luck moving their software to another platform in the future.
But I'll echo you, every time I've learned something hard, it's because I got way out of my depth and had to learn how to swim all over again.
I think this is kind of a given, today. I don't know many healthy, growing organizations for whom their "sysadmins" are not either originally developers or proficient in writing at least domain-specific code (I have always said that I am a software developer whose output is systems rather than web apps, because it's true; right now, with my current projects, I just wear both hats and get on with it!). Even the term "sysadmin" has largely disappeared in my neck of the woods; it has been largely replaced with "SRE" or similar, but that sort of position invariably seems to have development connotations.
I suspect I'd have a hard time finding employment doing the kind of work I'd want to do at the kind of salary I'd expect to earn. I'm a decent programmer with broad but rarely deep experience, a better than average sysadmin with ridiculously broad experience, a passable designer (better than half of the "real", but merely average, designers I've worked with over the years, but so far behind the good ones that I'm hesitant to use the same term to describe what I do when I build websites), a passable sales person, a pretty good writer and copy editor, and the list goes on and on, because I've run my own companies for the past 17 years. I've touched everything that a business has to do, and I've somehow muddled through and kept the bills paid and the customers coming back.
But, I'm not a "rock star" at any particular task. I couldn't wow anyone with my algorithms knowledge, though I've always figured out how to solve the problems I needed to solve. That's not a very compelling sales pitch when talking about a $100k+/year job for a company that has a specialist in all of the above-mentioned roles.
So, I think it really depends on what you want out of life. If you want to maximize security and income, focus on a high value skill. Become the best in your market, or as close to it as you can manage. Eschew all distractions from that skill; don't fuck around with weird Linux distros, figuring out how DNSSEC works, building your own mail server, setting up CI, self-hosting all of your own services and web apps, or otherwise becoming a "jack of all trades, master of none". If, on the other hand, all of those distractions sound like the best reason to be in tech (and, that's the way it's always added up for me, even when it's cost me time and money), and you're willing to take on a lot more risk building your own business (whether consulting or building products), I guess being a jack of all trades isn't so bad.
But, and this is a big but: There's only so many hours in the day, and so many productive days in your life (and you also have to take time away from productivity to have a life outside of work/tech). As I get older I realize more and more that I have probably valued my time less than I should and valued my ability to effectively DIY my way to success too highly. I've spent many hours fucking around with stuff that I could have paid someone a few (or a few hundred, or a few thousand) bucks to make the problem go away, and it would have been worth it in a lot of those cases.
If you aggregate all of the "Every developer should know X" posts and blogs, the list would probably be very long. It only promotes shallow signaling instead of actual competence (I only need to know enough about X to make people think I know about X).
Meanwhile, your salary will still only compensate you for one skill set: software development.
Devs will slowly learn the relevant knowledge anyway, just at a slower pace than the immediate needs. And yes, after a certain number of years, that dev could be good at both. But you can't only hire devs good in both places for every position at every company.
I see no harm in one having basic experience in multiple fields. Especially when those fields are related. Actually, this concept I kind of "market" it among my circles. A mobile developer should know the basics of web development and vice versa. That way they communicate better.
I claim that already happens naturally. It's our drive to quickly build a niche (e.g. "I'm a professional X developer"), in addition to insecurities that lead to saying "X is not my responsibility", is what gets in the way of expanding our fields of expertise.
That would be mostly Python these days. If someone here would touch Perl on my systems, they're gonna have a very bad day. Sure I wrote stuff in Perl back in the days, but those days are over.
I see this as Perl's problem: to be good enough at Perl, you'd have to frequently use it, but Perl is in my eyes only suitable for quick hacky run-once scripts - which should not be written frequently, so you shouldn't be good at Perl. My Perl is pretty damn rusty these days.
If someone is still writing large scripts/apps in Perl these days, I question their judgement in technologies and ability to keep up with the times. Sure you can write larger scripts in Perl - but what's the point? You have to take care not to make things unreadable, while when using something like Python, it's much harder to make a script that's unreadable.
Yes. Where I work, they're all expected to be able to cut code. They might pair with devs at various stages, but a sysadmin who can't write code isn't going to be able to work with some of the more modern frameworks for orchestrations because they are in essence DSLs: they _are_ code.
> Plan an invasion
This is actually a massive undertaking. An undergraduate at MIT taking a semester-long course on this will barely scratch the surface of it. Furthermore, you're never going to suddenly and unexpectedly need to know this. Any situation where you plan an invasion is going to be preceded by spending a long time getting into the position where people trust you with their lives and the fates of their nation.
> die gallantly
You're only ever going to be in this situation once, and probably not even that. Why does it matter how gallant your heart attack is?
These skills make a bit more sense in a world where most of us need to march off to war. Happily, we don't live in that world.
You should prepare for the situations you are only mildly unlikely to be in and where your skill matters.
Depends how old you are.. some historians are keen to point out that the global climate is very similar to the conditions just before WW1. Will you be of conscription age if WW3 does break out in the next decade?
> You're only ever going to be in this situation once, and probably not even that. Why does it matter how gallant your heart attack is?
I think doesn't exactly refer to the act of dying, but is more along the lines of "The object of war is not to die for your country but to make the other bastard die for his." So don't exactly want to die; rather, you want to avoid it, but should it happen, you just want to make it very expensive.
But of course, it could also have nothing to do with war; it could be about how you face death, and how much of a burden you leave to your loved ones. (E.g. don't commit suicide leaving a note that tries to shift the blame to your family, or whatever).
May be. Not only you understand better the needs of software developers. But also, you are able to automate a large chunk of your work. Paraphrasing Larry Wall: Sysadmins should be Lazy. "Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. ..."
The skills I require of my developers depend on the rest of the team and the project.
A server-side developer who never deals with ops is like a chef who never tastes the food. It's in theory possible to get right, but in practice the results tend to be poor.
Of course, the more someone knows, the better. Knowledge and experience in any area of technology can improve understanding of all the others. But nobody has time to learn everything, and there's way too much to learn. Time given to learning more about sys admin issues is time lost to other potentially valuable knowledge.
It's a good area to learn about, and it is essential to being a strong backend developer, but through good architecture and management practices, there are still plenty of ways to make very high value contributions for a developer who hasn't spent much time focusing on sys admin.
You might say that's not a "sysadmin issue," but I have seen it happen three or four times now and in each case it was the "sysadmin" (read: devops engineer) who caught the problem and explained it to the offenders in question. (Maybe it's a "build engineer issue"...but at most companies I've seen, he or she is probably the "sysadmin", too.)
Huh. Hands up everybody who is working at a place with good architecture and management practices?
Knowledge of and experience with the direct downstream and upstream of one's work is different than general knowledge. It can in theory be made up for by high-ceremony processes and strongly controlled interactions. But in practice that mostly doesn't work in software development.
Front-end developers don't need much server ops knowledge because that's not generally the direct upstream or downstream for them. But the principle still applies; they will be better if they have experience with their upstream and downstream.
If there is a sysadmin in your development team and this sysadmin has something to say about system's architecture and development workflow, then OK, you don't need any of your programmers to be a decent sysadmin. Otherwise, you need to get the sysadmin.
> But nobody has time to learn everything, and there's way too much to learn. Time given to learning more about sys admin issues is time lost to other potentially valuable knowledge.
And then we have Homebrew, which I constantly hear is atrocious and breaks software on updates (incorrectly managed dependencies), and its developers don't understand the necessity of using cryptography for transporting packages. We also have this whole idiocy of deploying software in production by recompiling it with `pip install', `rbenv install', and `npm install'. And then we also have incorrectly built RPM and DEB packages published by software developers (InfluxDB and ElasticSearch are common offenders, Riemann being another one when I checked long time ago).
And mind you, I don't use MacOS, I don't develop web applications, and I package and host additional software myself, so how big are these issues when they got my attention? What was it again with your valuable developer's learning time?
Client and Server folks were on separate floors of the same building. We didn't interact much at all, except by trading bugs back and forth. The management chains met at a VP. Three or four times a year we tried to coordinate a release, and it always took at least a month. Getting a feature out the door might take a year, with all the paperwork and pipelining of release schedules.
Ops was in another building. The only things that both Client and Server teams were sure of was (a) they did a bunch of customization of our stuff so that it would work, and (b) they hated us.
Support was in another state. We were not allowed to talk to customers. Maybe once a year Support would fly in to talk to the teams about pain points. I think we did an okay job addressing these, but it took a long time, and customers suffered a lot.
I won't talk about the disaster that ensued when Scrum was thrust upon us, or the splinter projects that spun off to try to fix things (but wound up being lots worse).
You have to be close to the customer or you won't know if you're succeeding, or even on the same page. You have to know what your software is doing in production or you're just sitting in an ivory tower pontificating about angels-on-the-head-of-a-pin nonsense. You have to spend time in the trenches measuring and fixing stuff or you're hatching an unmanageable disaster. The good news is that most of this is actually kind of fun. The bad news is that, when managed badly, this can turn into a horrible and soulless grind of pager duty and making legacy code even more legacy to fix wee-hours downtime.
I still get a rush when I get feedback from a real, live customer, and I think that isolating your teams from customers is one of the worst things you can do to a team and to a product. Getting teams to work on ops and support aren't bad ways to improve this.
But we learned that we needed it to go the opposite direction too. We had ops people who, when given a corporate-wide mandate to apply a security patch or some such task, would log into every machine and apply the patch, despite the fact that we'd been practicing immutable infrastructure with zero-downtime deployments. We hadn't given them the necessary exposure to the dev side to understand that you had to apply those fixes to a base image and trigger a redeploy. There was a lot of finger pointing a couple of weeks later after it was discovered that the fixes were overwritten by an application deploy.
If you have a small organization (say <10 engineers), it's crucial that every developer writing server side applications can also do at least some sysadmin work. As the article says, it leads to deeper understanding and it really helps when thinking about scalability, fixing certain kinds of issues, etc. It also often shortens the feedback cycle and requires less throwing over the wall. As a bonus, you increase the bus factor.
Automation is the key though. If everyone connects to the boxes and does random things manually over ssh, nothing good will come out of it.
Still, you need to have a person or two who are responsible for the vision of the architecture/systems and who make sure that things don't go off the rails.
Sometimes engineers will not leave enough space, use weird fasteners, etc. that make a simple job much more complex.
A failure to understand construction concerns also played a role in the Hyatt Regency walkway collapse. The original design was poor, but redesign to address construction difficulties accidentally weakened the walkways further.
> Havens Steel Company, the contractor responsible for manufacturing the rods, objected to the original plan, since it required the whole of the rod below the fourth floor to be screw threaded in order to screw on the nuts to hold the fourth floor walkway in place. These threads would probably have been damaged and rendered unusable as the structure for the fourth floor was hoisted into position with the rods in place. Havens therefore proposed an alternate plan in which two separate sets of tie rods would be used: one connecting the fourth floor walkway to the ceiling, and the other connecting the second floor walkway to the fourth floor walkway.
> This design change proved fatal. In the original design, the beams of the fourth floor walkway had to support only the weight of the fourth floor walkway, with the weight of the second floor walkway supported completely by the rods. In the revised design, however, the fourth floor beams were required to support both the fourth floor walkway and the second floor walkway hanging from it.
https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse...
Afterwards, one of the supervisors showed me the difference between wiring done by an electrician and wiring done by an electrical engineer. He pulled on each wire of the relay panel. The wires done by the electricians didn't move, but most of the wires done by the electrical engineers popped right out.
Of course in HS/college I ran a website that was a frequent target of hate in the late 90s/early 2000s and it taught me about XSS and CSRF before people invented fancy terms to describe them. It also taught me about HTML/JS escaping, DoS/DDoS, SQL injection, and how all your defenses are useless if someone social-engineers their way into root and nukes everything. I have the assumption that everything is compromised and user input is toxic waste burned into my subconscious.
It was the best training I could have for writing software for the Internet. Just a couple of months ago we noticed one of our core apps was not scaling no matter how many docker containers we had spun up in Mesos. Spent a week breaking it apart using that experience and being able to make changes directly to the code base and being able to talk to devops in a language they understood, and in under 5 days we managed to identify and fix 7-8 different issues.
I would value a dev with sysadmin experience _far_ higher than one without in a tech business with a headcount under 500: it's going to lead to fewer problems and issues in the short and medium term.
That experience naturally lead to me becoming a sysadmin during my study at university. It was a fairly straightforward application of what I already had learned with a much larger scale of management. The primary thing I gained out of it was a drive to automate everything. When I started that job most of the sysadmin work was manual, but a few of us spent a huge amount of time focusing heavily on automation and when I left most of the work was automated and we were just doing meaningful firefighting and supporting development.
As an engineer, the main benefits have been understanding how my software is going to run in an actual software/hardware stack, easily jumping into a production environment and debugging complicated issues, being able to quickly have my OS do what I want, and that drive to automate everything. A lot of that informs how I build software and in general it feels like it makes me a lot more productive.
The example in the article isn't what I tend to see in real life. What I do see are things like:
- Not knowing about various limits (number of open sockets, or listen queue depth for example), how to know you've hit one, how to deal with it.
- Not handling various error situations correctly (can't open file due to permissions for example)
- Security issues. ( socket listening on 0.0.0.0 when localhost would work, for example)
- Making assumptions about things like "current working directory" or "certain environment variables will be already set for me"
For many of these, including a sysadmin or system knowledgeable architect in the right discussions would suffice.
It's not the developers fault though, at least not as much as devops types would like you to believe. I think the author has a good point, in that its good to get Devs thinking about real world environments on deploy, but the real world is much more complex than concurrency of servers.
All that being said though, very rarely have I as a sysadmin of 10+ years seen problems so easily attributable to devs. Of course I haven't lived in hn/sv startup land either, so take that into account, but failures in systems I have seen have almost always been a failure of management, up to and beyond C level.
I could go into detail, but I'll save it for another time. Suffice it to say, what businesses need to be doing is getting better CTOs and CIOs who can bridge the gaping chasm between sysadmins and managment.
Devs, you keep being Devs, and let the sysadmins be sysadmins. Cross train and communicate when you can, but don't fool yourselves, it is management that bears the responsibility and burden of you both. Management just doesn't like to admit that to themselves or anyone else, so don't play into this Devs vs sysadmins dialectic too much, lest ye find yourself the scapegoat next go round.
The sysadmin who can't write good, maintainable code is going to rapidly see their positions reduced to sinecures in large and slow companies. That may be enough to finish out a career, but I wouldn't bet on it if I was under 50 (and I don't bet on it; I have always, as said elsewhere in this thread, framed myself as "a developer whose output is configured systems" rather than "a sysadmin" for this reason). Similarly, in an age where infrastructure-as-code is becoming the norm, you had better be able to work with it or, as a developer, you are very limited in what you can do without being blessed by somebody else--and the set of environments where that's gonna fly is shrinking, too.
This is emphatically not to take any weight off of the shoulders of management, to be sure. But rather that I feel very strongly that what divide existed between these "disciplines" no longer exists, and both developers and traditional sysadmins need to move to catch up.
I completely disagree, but respectfully. What I think we are lacking in this discussion is a differentiation between what we mean by sysadmin as a product and as a job description. Systems Administration is a aggregate management of the technical infrastructure. (for $reasons).
In super small technical infrastructure, such as webdev startups, there is very little active sysadmining to do if done properly, but as complexities grow, you need multiple people to perform all the various duties needed to maintain a system. In the performance of these duties, there are various descriptions with varying levels of requirements.
What I postulate is that traditional businesses in seeing the agility of the dotcom and startup culture have been attempting to cut costs in the technical infrastructure, but for the most part because the managers of the technical infrastructure (the sysadmins) haven't had anyone to advocate on their behalf, this has resulted in poor business performance bottlenecks.
I would be curious to hear what other have to say, but in the "shit-hot Perl slinger." days, usually the senior sysadmin was the slinger, and he reported directly to the CFO and CEO, if not ownership.
What I argue is that systems have gained in complexity from a computing infrastructure standpoint such that this old structure no longer worked well, hence the creation of the CTO/CIO class(very similar). The problem is, they aren't doing a good job in my opinion. Therefore, in this current business climate, my argument is that the main problem is we already have good code slinging sysadmins on hand (or can train them), but what businesses need/the industry is lacking, is business/political game aware senior sysadmins to make up for that failing of the C's. Hence I disagree the days of non-code slinging sysadmins are going anywhere. Indeed, some of the best senior sysadmins I know live in meetings, but if they are performing well in fulfilling that role, and not slinging code, but instead making big picture, high-level overview decisions and then monitoring progress, I don't think there is anything wrong with that. Now, if we got CIO/CTOs back on the right track, the political/business game demand could fall and those sysadmins could get back into hard work, (which just happens to sometimes involve code-slinging to solve problems.) Devs are an entirely seperate entity, but still part of the process, in anything other than a pure web startup type businesses with little to no real infrastructure (eg, workfrom home contractors).
Of course I want to qualify this in that this is ancedotal and I admit I haven't seen every environment, but I have seen many environments (as a contractor, seeing more insides than the guy going for retirement), from fortune 500s to 2 man lawyer shops.
Any business that can see this issue coming and address it head on will be far ahead of the game. Those that don't, will one day have very rude wakeup calls as the complexity exponentially increases and they don't have the structures in place the handle the demand, mostly due to lack of foresight/vision.
I'm pretty confident that I've seen where we're going with this. The management piece of the puzzle is totally important...but the practice is going to continue converging with every other bit of software development.
A frontend UI person who can write their own backends is great. A backend developer who knows javascript and can build their own frontend is great.
A coder who manages their own cluster is great too, as is a sysadmin who who can write code.
And a developer who can do customer service, and therefore can fix a problem for every customer at once through modification of the application, is better than just someone who can answer the phone and make the customer happy.
All this is to say that someone cross trained will always add more value and will also cost a commensurate amount.
Man...I wish the latter was the case. I ended up going into consulting precisely because of the way that salaried employees are valued in tech right now. I literally am all of those things, I am comfortable and have delivered at a high level mobile, web, backend, and infra projects--but the "market" loves valuing those roles individually, and not the synergistic capability of being able to do all of them.
Consulting is fun, but finding a place where those talents actually are valued would be rad. (Anybody out there: have an opening for somebody who can deliver value at literally every level of your engineering organization while always being game to help bring your other developers up? Email's in my profile. ;) )
Find a company that values "founder's mentality" or "ownership", and that organizes projects in a way that can take advantage of it. Where I currently work, there is a lot of opportunity to "start up" new ideas, and driving them successfully benefits substantially from the the founder-like ability and desire to wear many hats. Part of this focus on ownership is the principle that every product team owns their vision, roadmap, technology choices, system stack, etc. from top to bottom. The larger platform is organized as services layered on top of services, that one team provides to another with a high degree of isolation and autonomy. There is no central "operations team" to punt to, and while there might be central customer service teams, they primarily handle routine requests.
I bet you will also find this in places that care a lot about customers (are "customer obsessed"), and spend a lot of time thinking about and examining what their experience is. A relentless focus on improving the customer experience is one principle that can lead you to look anywhere and work on any problem.
P.S. A team I work with is starting up a new operations excellence group to drive the next level of improvement to our operations/availability/SLAs/efficiency, etc. in our division. They are looking for talented engineers comfortable wearing multiple hats, who can work both at the architecture level one moment and switch gears to get deep into code the next. If anyone's interested in driving engineering excellence cross-functionally across many teams in that sort of way, see my profile and hit me up!
If you're good in multiple areas the only way to really get paid what you're "worth" is to start a company and use your skills to create an amazing product.
Because you're right: the market doesn't value a true polygot.
As it happens that's the other side benefit of consulting--being able to build a product with downtime. And I am! But it's still a lottery, and risk mitigation is a thing. So I like hailing for interesting offers to come my way.
Sure just do our HackerRank coding challenge and implement some algorithm that will be completely irrelevant to your job in a web browser under time pressure.
What I think is more practical is understanding when certain problems fall outside of your own scope or capabilities and when to engage someone else for their advice.
Of course developers have to write code for a logical model of a machine that isn't necessarily the same as the laptop they're working on. But I don't think anyone would ever dispute that.
Storing pictures on a local disk when the software is supposed to run on a cluster has absolutely nothing to do with sysadmin experience.
If a developer is building an app for 100K users the same way they'd build an app for 100 people, the systems architect dropped the ball- not the developer.
In my experience a developer doing one year in an Operations department gains some insight in what is going to be important in the longest phase of the software life cycle, that is when it's exposed to customers and the company has to react quickly to problems. Proper logging, anything that can help pinpointing the cause of problems and even hot patch them at 3 AM.
The usual lean startup might have little thoughts for that (is it even going to have customers?) but established businesses do.
If it's 6 months to develop and it runs for 10 years (with maintenance and new features), which phase is more important to a company, development or production? I'm a developer which did a couple of years of operations and I've little doubts about it. It's where the company makes the money from.
I often see developers trying to replace it with bloated, complex piles of hipster software. While a devops team is attempting to build a toy Google-like infrastructure on 50 nodes for weeks, another company is deploying code just fine using some 15 years old setup with netboot + disk imaging system + OS packages.
(As an aside: I mentally replace the words "hipster software" whenever I see it with "things I don't understand" and the sentences never seem to change their meaning.)
What I don't want to mess with is the "DevOps" tools, like Docker and rest of cloud orchestration stuff. It's a very complex field and I couldn't care less. If I work on a project like that there's always somebody who can do that kind of setup.
If you're a large business you should be automating your sysadmins with devops/SRE techniques. If you're a small business you should be outsourcing that work to companies that have automated it for you.
That's why cloud providers and associated services have seen enormous growth.
Chef etc. aren't "home repair." (Well, maybe Docker, and it shows.) They're a way of expressing subject matter knowledge. Still gotta be a developer to do that expressing in a way that isn't going to kill you, either directly or because you write code that your fellows burn you at the stake for.
Reading the article, the sysadmin is described as the person who constructs and maintains the environment the code runs in, including the physical machines, but also things like dependency management (I infer).
Given that just about everything except the physical machine can be handled through devops automation (from experience), and those things don't require "special" skills other than docker/ansible knowledge, why are sysadmins still considered separate from software devs?
On a more opinionated note, I think that using people, and not code to setup the operating environment of their application is pretty inefficient nowadays.
1. In CS150 one has to build a hardware computer. 2. In another class one has to build an OS. 3. In another class one has to build a Database. 4. In another class one has to build a Network.
Education is key. Understanding the TLB inside the CPU gives one an appreciation for context switching between the only 2 users the CPU has hardwired into it: kernel and user.
Being a sysadmin is insufficient experience as education. Every developer should know how to build a hardware computer from the ground up.
Computer science at Berkeley doesn't have a "Java" class. The language one programs in changes depending on the Professor and topic. That way one doesn't get too attached to a language.
Most developers do not understand the hardware implementation of a thread, or now-a-days a docker. As a result both get used wildly incorrectly.
Threads are useful blocking on IO to keep the CPU from starving. However, switching threads simply to swap CPU bound jobs is inefficient. Just adding a thread doesn't guarantee equal service to users just like adding processes does not.
Developers are using dockers today who have no clue why they are doing so...it's just that everyone is doing it and they do not want to appear stupid.
Experience as a sysadmin is no substitution for education.
Personally, I feel that system administration experience of some sort is essential to development skills, and development experience of some sort is essential to system administration.
Communication and leadership skills are essential to both. It _used_ to be OK if you were the jerk at the office if you were good enough at your job (sysadmin or developer). That's no longer the case because we've progressed well past the point where a single developer or sysadmin can be enough of an asset to look past their ability to work well with others.
Operations needs stability. Developers need to hit moving targets. Sysadmins need to keep things manageable, compatible, and secure. These aren't incompatible goals, and usually when you get the techies talking they are sympathetic towards each other's challenges and helpful to one another. With as many project managers, engineering managers, manager managers, directors, and executives in the mix I wonder if the problems in all these environments isn't more of a historic issue with leadership failings.
Which means the ones with actual, marketable skills aren't working for the government.
Spending months waiting for a sysadmin to perform a task you know takes about 3 minutes is great fun.
I predict sysadmin culture and skills will be the next Fortran.
To extend the analogy of the house on a slope, if you don't tell the developer you need a house designed to be built on a slope, that is a problem with the spec provided to the developer.
Although it can at times be more efficient for a dev to have sysadmin experience, making blanket statements requiring all developers to come with such a background is just sensationalism.
I think the lesson the author is really trying to convey is the importance of learning about distributed computing [1] concepts and not necessarily system administration.
Can you point some good resources about sysadmin I could use to improve my knowledge on the subject? Note I'm a noob when it comes to all this server-side magic.
The Phoenix Project by Gene Kim is kind of a more modern uptake on it, but both can be read easily by people outside of the field and I doubt the first one will ever not be relevant.
Both are more about establishing proper ops methodologies. If you're looking for something more low level, like a Programmers guide to sysadmin I can't think of anything off the top of my head.
I do feel all devs at one point should have some sysadmin experience - if not professional, then informally.
That said, sysadmin is strongly divided into 2 types of tools - configuration and code.
I love tools that can be coded (as an example - Gulp), over configuration (like Grunt) - as they generally have a lot less undocumented "gotchas" and getting started is generally a lot more simple. (I'm looking at you Webpack!!!)
In organizations with uncoordinated or siloed management, this leads to infighting... sysadmins try to stop "troublesome" devs from making changes at all and actively slow down changes in the name of stability and developers at the other extreme try to get changes in without caring about stability and blame sysadmins for that.
Great management with experience in both will find ways to incent the teams to introduce regular change while maintaining stability.
Developers don't have the burden of maintaining and upgrading multiple applications on the same server, with conflicting dependencies. 24/7. Sysadmins don't feel the pressure by end-users to deliver new features yesterday.
At the moment developers are winning because Docker. But when they grab that responsibility they will be the ones called when their 50000 containers are being hacked because vulnerabilities. And they will be under fire for the system being down and that costing the company a lot of money, so everybody breathing down their necks.
It may have something to do with my education being EE, but that's not the heart of it. I never practiced EE. I taught myself (more or less in order) building circuits, programming, building PCs from pieces, and elementary system administration. I know there are lots who never "get" all three, but the best I knew did.
But at some point, you have to acknowledge that developers can't know everything. Go deep or go broad, but accept that both paths have their limitations and benefits. Maybe in some cases you'll run into a bug you created due to your lack of sysadmin experience, but don't feel bad about it...your experience has led you to other types of expertise. Fix it, learn from it, and move on.
For that matter, I suspect most sysadmin / ops teams would be happier if developers could only strip "just" out of their vocabulary (and vice versa) - nothing more annoying than "could you JUST do {thing asker doesn't understand and thinks is trivial}"
Frankly, at the end of the day, most businesses don't want something that was "working" breaking. All the conflict comes from that one desire. There is a reason System Admins have to do the "Patch Tuesday" dance and despise any software that just updates by itself. Getting yelled at because Chrome updated to a version not supported by your ISV or your local developers is an amazingly fun experience.
Yep, System Admins have to be the company nanny. It sucks, but the apps need to keep working.
Sure, it helps if an individual is not entirely myopic, and would be great if that person can wear multiple hats with skillset spanning all those disciplines.
However those different labels exist primarily they align to unique mindsets and solutions to a problem in a mutually exclusive manner.
Do you want a jack of all, but master of non?
Seriously, how many individual out there do you think have the capacity to develop their career so they have deep capabilities for all of those disciplines?
- Plenty of software developers work for small- to mid-size companies where the Node or Rails server running on your machine is nearly identical to the one running in production.
- Plenty of software developers work exclusively on the front-end, which means that the computer your code runs on in production is very very similar to the one you develop on (although then you have the added concern of testing on lower-end mobile devices, other browsers, etc)
Where I come from, that's called "knowing how to use a computer".
Or at least it was, until Windows et al arrived.
(Interesting how the user-interface technology advance called the GUI, decreases the efficiency of the human/computer interaction.)
Except ... for those who still regularly use a Unix-like OS, that knowledge still is quite basic and, thus, surprisingly difficult to trumpet on a resume.
But given most engineering projects are crud apps without scaling problems, and PaaS companies like Heroku totally abstract away the system adminstration piece for those projects... I certainly wouldn't recommend a new engineer spend any time learning system administration.
Bonus points if you make an actual product that solves a problem and also practice all of these skills.
Once again, like I said in my other comment, even in web startup land, this is a failure of management, in particular CIOs and CTOs, and the management that selects them.
The problem is that companies can usually manage to survive for quite a while ignoring these problems. There is little short-term feedback mechanism for duct taped systems... Until that day when shit starts dying and no one can fix it. Or a cryptovariant hits the file server. Etc.
Snark aside, if the post was headed "Software developers need to understand the environment where their code will be running or they may not build it properly", which is the point being badly made by conflating "environment" with "some kind of commodity x86 with a standard OS", it would be a lot more applicable.
I really spend the majority of my time trying to slot something into place in a way that no one will notice that doesn't disturb existing stuff...often that means duplicating bad behavior because its become a dependency.
In what city or company is the barrier to entry for software developers so low?
I just can't imagine paying above median income for a software developer who can't install, for an example given in this thread, Visual Studio.
In that era, I think WalMart handled this apparent developer/sysadmin confliact quite well. Believe it or not, even though we (the whole company) had exceptional uptime, we were also extremely agile. LOTS of code was written and rolled out across thousands of sites, multiple times a day.
There were a number of keys to this, and I'll enumerate a few.
1. Most new hires (those that had minimal previous experience) to development positions had to spend their first six months working at one of the four or so major help desks. Note: they were paid their target salary, but in an hourly fashion. 2. The various operations teams had complete and final say so over what went out, and how incidents were handled. A couple of the big operational areas were Unix Operations, Network Operations, Windows Operations and Mainframe Operations. I called them 'teams' but each had a number of teams, and their own help desk. 3. Any time there was an impacting problem associated with a program developed by team X, a war room was called by the relevant operational area. A member of team X (a developer) had to stay in that war room (switching off between team members if it ran very long) until the production problem was not only fixed, but also deemed unlikely to recur, except in cases where that dept of a fix would take a long time. 4. Every development team had a pager rotation, with rigorous expectations about responding to such pages. This was primarily to support the previous point. 5. Because of the enormous operational scale, all of the major operational areas had dedicated teams focused on automation. My team was that team for the networking area. Furthermore, most of the rest of the operational folk read/wrote code to some extent.
In short, incentives were aligned. Teams that wrote externally facing code felt pain if the stuff they wrote and released caused problems. Operational folks wrote/managed/interacted with tons of their own code in order to manage the enormous infrastructure. Also, ops folk were far more willing to let things move with velocity knowing that the people who actually wrote the code would be required to support it, globally, any time of the day or night.
Another, perhaps even more important reason we were so successful during those years (and the years before) was a strong and vibrant esprit de corps. The entirety of Information Systems was, at the time, around 2000 people, and we were facilitating double digit year over year growth over a 150 billion dollar company. We had over 5000 remote sites in 15+ countries, with a diversity of software and infrastructure that was honestly pretty astounding. Each of those sites had quite a surprising amount of infrastructure.
We worked hard, and we produced huge velocity with fantastic uptime. For example, the network achieved six 9s of availability a couple of quarters.
In end, while things were sometimes contentious, we trusted each other, and only minority of teams were forced to work bad hours for any length of time.
The argument about understanding how code scales beyond one computer is fallacious. In fact it's quite easy to learn and practice all kinds of distributed high scale architectures without getting up from a desk.
I will agree it's important to understand the people and work connected to your job. It's probably a good idea to eat lunch with the sysadmin, or QA, or UX person.
Would also agree its important to have respect, empathy, and collaboration others, but it doesn't mean you need to switch jobs.
The mindset that you are describing is why that "devops engineer" that gets hired so very often ends up being burnt at both ends being the savior of the team because, unlike the developers, he or she does understand both sides of the equation and is able to solve the problems that the incurious developer cannot. I would strongly urge that you reconsider.
And, for your own sake, please excise the word "fallacious" from your vocabulary. It will help you, I promise.
Ridiculous. Many developers have specialties that take years to gain proficiency. If there were no difference we could just replace a math PhD doing computer graphics with a sysadmin. Sometimes it's possible, but the blanket statement does not hold up.
>I would be a bad developer if I did not understand how the systems my code runs on work
I agree, but so what? Becoming a sysadmin is not the only way to do that. You shouldn't confuse what you've seen work, with being the only way something can work.
>[your] mindset is why "devops engineers" get hired and very often end up being burnt at both ends
You’re reading way too much into this. I never said a sysadmin rotation couldn't be helpful for some. I said devs don't necessarily have to do it to be great at their jobs. I wouldn't pull a dev who was, in the zone so to speak, being highly productive into a sysadmin role misguidedly thinking it would have no impact on delivery.
>[sysadmins are] able to solve the problems that the incurious developer cannot
I never implied I wanted “incurious” devs who couldn't solve problems to the extent they needed a “savior” as you put it. Maybe you are projecting your past experiences onto others based on overzealous inference? I didn't say what you suggested, and I don't believe it.
> please excise the word "fallacious" from your vocabulary
What are you talking about? The definition is “based on a mistaken belief”. I claim the argument that devs cannot understand scale out architecture without being a sysadmin is based on a mistaken belief. Why are you so against that word?
Because, to be frank: it makes you sound like a tool. That's what 'greglindahl was referring to in his post, 'cause I said exactly that before I edited it to assume good faith and be nice about it. But leading off your reply with "ridiculous" confirmed that you're okay with that. I'm not gonna play this game with you; I'm having way more interesting and way better conversations in this thread with people who don't wanna dance that dance. Haveaniceday.
...also, man, don't tell me you're on Hacker News while you're camping...
Should a //everyone// be in other roles full time? Depends.
Should a //everyone// have had exposure to expand their knowledge? Yes, absolutely. It should also be refreshed so they don't forget.
Most adults from time to time are exposed to this for 'common day to day tasks'. Either in the form of being an assistant to someone else doing a task or in directly doing it themselves.
etc. If you are still using docker, puppet or worried about scale/security... you are living in the past. (one ex: https://github.com/struts3/what-demos )