2015-12-31
Fear and Loathing in Systems Administration
This year I participated in SysAdvent, a tradition of Systems Administrators to submit to write a blog article of their choosing. Similar to a Conference, a Call for Proposals is published, and if interested, you propose a Topic (a title and brief description are all that are required, if I recall correctly. My proposal was accepted, an editor was assigned, and due dates were set.
After fleshing out some further notes and constructing an outline, I set out to procrastinate until a couple of days before my due-to-editor deadline. My editor, the fantastic Shaun Mouton (@sdmouton), promptly reviewed my content for style, sense, and sanity, and when we came to consensus that it was good enough, he submitted it for publication.
I offer my thanks to Shaun and the rest of the SysAdvent team for maintaining this tradition, and I sincerely appreciate the work that goes into keeping it going. While I'd had this bunch of ideas floating around in my head (largely as a conference presentation), it was their work that made me sit down and write it out as prose, rather than a slide deck.
Now, with permission from the author (
Fear and Loathing in Systems Administration
Written by H. “Waldo” Grunenwald (@gwaldo)
Edited by Shaun Mouton (@sdmouton)
In some companies, these folks have the best computers in the place. In others, they have to live with the worst. Their workspace probably isn’t very nice, and almost certainly has no natural light. If there is a pager rotation, they are almost certainly on it. If there isn’t a rotation, they’re basically on-call all of the time.
During the course of a normal day they might have to switch contexts between disaster planning, calculating power and HVAC needs for a new datacenter, scrambling to complete an outage-driven SAN migration, rushing to address urgent requests to help people with their email, to troubleshoot a printing problem, or suss out why someone can’t get to their electric company’s bill pay website. They may be the sole person with database expertise in the company, or they may work on a team of dozens.
The work is largely invisible except when something fails, in which case it’s highly visible and widely impacting.
These are typically cynical people, because there are only so many times that you can’t make the team/department/company party for ostensibly “celebrating our successes” because something’s broken, and you’re left to clean up after the “success”. There are only so many times that one sees a new project announced and begins to hire more people. When asked who’s going to support the new project, the response is a blank look and “you are”. The “…of course.” may not be vocalized, but it’s probably there. When asked how many people they get to hire to help with the workload, the response is a combination of “sorry, but there wasn’t anything left in the budget”, “it won’t be that much more work”, or a variation of the “team player / good soldier” speech. There are only so many times one can take getting your requests for training or conference budget rejected out of hand, and have your requests for training or conference budget laughed out of the room.
They probably have basic working knowledge of a half-dozen programming languages, but most likely they often think in Shell. They probably know at least three ways of testing if a port is open, and probably have a soft spot in their heart for a couple of shell commands.
They may have seen or participated in a DevOps initiative that consisted of a team or position rename, or helpfully suggested that they install some Config Management and Monitoring software so that “we can DevOps now…” or “so we can do Agile”. When they hear “DevOps” or “Agile”, what they are hearing is is Let’s take the same people who can’t handle a planned release schedule or make whatever effort that they need to squeak by the Change Board and Release Management requirements, and give them unfettered access to Production. Clearly, I’m not paged often enough.
So what is one to do? How is one to maintain their sanity in the face of increasing job scope, increasing demand for access and velocity, and little hope for an effective new-hire count? Not to mention continuing to juggle the existing volume of requests, and continuing to grease the existing gears to keep the machine running.
Please note that I’m not saying “just”. There’s nothing just about this situation; there is nothing simple about any of this, and Justice hasn’t been seen in a long time in an environment where this is the norm. Most of these changes are difficult. They will take work, and will require convincing other teams to join in your cause.
Because SysAdmins are typically responsible for the environment, the easiest way to assure that the state is stable is to lock everyone else from it. While this helped with the goal of “keeping out unexpected changes”, it had a number of side effects.
First, a kind of learned helplessness has set in. Your customers and teammates became so used to being “hands-off”, that they don’t have the wherewithal to meet reasonable expectations. Since they’re uncomfortable making any changes, all changes must be made by the SysAdmins. This leads to your time being taken by having to perform lots of low-value tasks.
Some teams settle on the pattern of “hands off Production, but you have access to Staging”, but this is fraught with peril. The most common problem that stems from this is “Configuration Drift.” Config Drift is when you have different settings in one environment (or server) than the others. When the cost to discover what Production looks like is high, it’s more likely that people will either use defaults, make assumptions, or use the same configs that they use in their IDEs. “Works on my machine”, indeed.
This is a problem well-solved by Configuration Management tools, but you still need to be willing to trust your peers and give them access. If you want to be part of the process of validating changes, you could put in place the structures that allow a pull-request and code-review workflow, something that your Software Engineering peers should be very accustomed to! Granting access to see the existing configs and the ability to propose changes also shares responsibility for your team’s environments and contributes to feelings of ownership. Denying colleagues the ability to effect necessary configuration changes contributes to the root problems of configuration drift and learned helplessness.
Your value is not in doing the work, but rather being able to make the decision to do the work.
I’ll be the first to say that “Automating ALL THE THINGS” is a flawed goal. At work, it’s usually said in the context of a Project, rather than part of a philosophy of Continual Improvement (Think Toyota Kata). You shouldn’t have to engage in an “Automation Project” to improve your environment. Build into your schedule time to solve one problem. Pick something that is rough, manual, and repeatable. Remove a small piece of friction. Move on to the next one. Hint: Logging into a server to make a configuration change should be a cue to implement configuration management!
While I agree that everything being automated, not everything should be automatic. Decision-making is complex, and attempting to codify all of the possible decision-making points is a fantastic way to make yourself insane. Not to mention that documenting your decision-making processes may be an unwanted look inside your brain. Caveat Implementor. (Or perhaps that’s just me…)
All of the units of work should be automated. But the decision to run the now-automated tasks can be left to a human. When you find that there is a correlation between steps, those pieces should be wrapped together. Automation isn’t a project into itself. It should be iterative. Pick something that’s painful. Make it a little smoother. Repeat. Ideally, you have time blocked out for Continuous Improvement. If not, create a meeting, or create a weekly project to do so. Review the issues that you’ve experienced lately, and pick something to make better. It might be worth making into a project, but it won’t be an ALL-THE-THINGS project. Create a scope of effort. Take the time to plan goals and requirements.
Whatever you don’t automate must be documented. Beyond the typical benefits of documentation, it also serves as “Functional Requirements” for someone else to pick up when they can help you with providing a solution. Try to recognize whether documenting or automating takes longer. Perhaps this piece of documentation will bet better served by “Executable Documentation” (i.e. code).
You should attempt to pick apart the parts of your work, and attempt to describe them. One way to make this a fun exercise is to use other job titles to describe the work.
Are you an “Internet Plumber”? How much of your job could be described as “Spelunking” into the deep dark caverns of Legacy systems?
If you want, you could ascribe Superhero names to these parts of your work. The added bonus is that it not only describes a role, but also a demeanor associated with them. When ‘bad code’ makes it to Production, do you go “Wolverine” on that dev team?
Could you describe part of your role as “Production Customs Official”? Are you the gateway to Production? If so, are you actually equipped to do that? Here’s a quick test: When you say “no, that can’t go”, do you get overridden?
More importantly, is this what you want to do?
Take someone to lunch. Preferably someone who you don’t know well. Ask questions, and listen to the answers. It is not time to defend yourself or your team. It’s time to find out what the business needs from someone else’s perspective. Ask what they think that your team’s role is in toward achieving that success. Ask what they think your team does well, and where there are gaps between what you have now and excellence.
You probably recognize their words, but you need to go out of your way to speak them. To communicate your message, you will need meet them on their turf. This may seem terribly unfair - “Why can’t they meet me on my terms?!” - but I’m guessing that has not been working out well for you so far.
Not only do you need to use their language, but you need to communicate over their medium. And identifying who they are is step one in learning to speak it. It’s probably not IRC, and only writing it in email is a good way for it to be ignored.
If you’re speaking to management, be prepared to write a presentation. Executives especially like to see a slide-deck. It doesn’t have to be slick. It probably shouldn’t have sounds or much in the way of transitions, but a presentation can help to lay the groundwork for a conversation.
Now that you have described your role, we also need to describe everything that you support.
What Products do you support? It’s entirely possible (likely, even) that the people and teams that you support don’t actually know what you’re responsible for. It could be argued that most of them shouldn’t need to know. But if you have been saying “no” to protect yourself, it’s a sign that you are significantly overextended. You need to have a real discussion with your leadership about your role, scope, and staffing.
In order to have this discussion, you need to prepare. You need to come up with a fairly comprehensive list of the products and teams that you support. This is a list of every team, and their products, the components and tasks that belong to you for each. Don’t forget all of the components that “nobody owns” but somehow people come to you to fix or implement (CI, SCM, Ticketing, Project, and Wiki tools seem to be common examples). Are you also responsible for Directory Services? Virtualization platform? Mail/Chat/Phones? Workstation Purchasing and provisioning? Printers? Do you manage the Storage, Networking, etc? Don’t be afraid of getting into details. It can help to provide clearly written potential impacts the company if some of these “hidden” services stop working? Your leadership might not know what LDAP or Directory Services are, but they’ll understand if nobody can log into their machines, they can’t pull information to build reports, and by-the-way nobody can deploy code because it relies on validating credentials…
What is most important to the company? What do you need to succeed? How much more staff do you need? What tooling or equipment would help you work more efficiently? Does code deploy even when it fails testing? How many outages have arisen due to this happening?
In order to have meaningful discussions with people in your company who aren’t necessarily technical, you need to be able to relate to a language that they speak. Regardless of team duties, the lingua franca of most teams is money. As Engineers, most of us prefer to think in terms of the tech itself, but in order to describe an impact, a unit of monetary value is a proxy for impact that most non-technical people can understand, even if they don’t grasp the details.
It is a helpful (if difficult and uncomfortable) habit to get into, but I encourage you to consider the components of cost that goes into every incident or task.
What is the cost of a main-site outage? How much revenue does this feature bring in? Why are you spending so much on infrastructure and effort to make that component Highly-Available? Why does it matter that you do that piece of maintenance? Show the negative value of doing things they way they are (Opportunity Cost), versus investing time to improve the automation around it. Describe how doing this maintenance work reduces your context switching, unplanned outages, and lost reputation of your company. Describe the benefit in increased visibility to the business, and Agency to be gained by your peers on other teams.
Why put in place these tools to let product teams self-serve? Describe that the features that the company’s teams spend so much time and effort (read: “money”) creating means nothing if those features aren’t available for customers to use. That having those features not available costs money in terms of feature billing, and reputation cost. If they claim that they’re doing Agile, but can’t do Continuous Delivery, they’re not really Agile, and the whole point of that framework is to improve delivery of value to the customer and the business!
Further, show how systems relate. It doesn’t have to be terribly detailed. Describe that the features that the customers use are reliant on x, y, and z components of infrastructure. Draw the lines from LDAP to storage to your CI tool to testing code to artifacts delivered to Production. Then show some of the other systems that have similar dependencies.
Once the picture emerges showing how everything is reliant on unexciting things like LDAP, your Storage cluster, and that janky collection of angry shell and perl scripts that keep everything working, realization will begin to dawn.
Congratulations, you’ve just effectively communicated Value.
Get Devs on-call for their apps. SysAdmins should be escalated to. Devs can triage and troubleshoot their own apps more readily than you can. They get to call in the cavalry when they get stuck. They don’t need to know everything about the systems, and they don’t need to resolve everything. When a fault occurs and they need help, they stay on the call, pairing with you as you diagnose, troubleshoot, and resolve. That way, they don’t need to escalate to you for that thing the next time it occurs, and can collaborate on automating a permanent fix.
When teams aren’t responsible for their products - When they aren’t paged when it fails - they are numb to the pain that they inflict. They’re not trying to cause pain; they just don’t feel it. It’s especially easy to argue this for teams that proclaim that they use Agile development methods: If they claim to want “continuous feedback”, there is nothing more visceral for providing feedback than the feeling of being awoken by a pager in the middle of the night. When the inevitable exclamation comes that “we can’t interrupt our developers”, ask if it makes sense to interrupt someone else.
Even being aware of the pain (say, hearing how many times you were paged last night) can elicit sympathy, but that’s a far cry from the experience of being paged yourself.
Further, this is what that list of responsibilities is for. Asking each team to take responsibly for their own products, you will still likely have a hefty list of services that you provide that you are on-call for. As these set in, point out the staffing numbers. This may be a matter of the places that I have worked, but I have never seen a Developer-to-SysAdmin ratio of less than 5-1. In most places it is much higher. By adding these teams to pager rotations, they drastically reduce the load on you. By not adding them to pager rotations, they are complicit in your burnout.
SysAdmins have a reputation for saying “No”. The people who are asking are probably not trying to make your life worse; They’re probably just trying to get their work done. They might not know what their “simple request” involves, and that it probably isn’t necessary.
But by not having Responsibility aligned with Authority, you may have been stuck with the pain of other people’s wishes. You know that fulfilling their request will cause you pain, so understandably, you say “no”. What often happens next is that they escalate until they hit someone sufficiently important enough to override you.
This is the basis for why SysAdmins feel steamrolled by everyone else, and everyone else feels held hostage by SysAdmins.
But all hope is not lost.
Stop saying “No”.
“Yes, but …” is a very powerful thing.
“Yes, but …” can be used to get you help.
“Yes, I can set that up for you, but we don’t have capacity to run it for you.” What happened there? You agreed that the request is reasonable. You set expectations of the level of support that you can give. You left the requestor with several options to continue the conversation.
When I say “Playing Telephone”, I’m talking about the situation where someone (let’s say a Developer) wants logs from the application, but they don’t have access to get them. They request the logs from you. You fetch the log requested and provide it to them. “No, not that log, this log…” You fetch. “Hmm, I’m not seeing what I’m looking for, could you check in here for something that says something like this …?” And so on, and so on…
I don’t know what you’re hoping to prevent by restricting access, but if this scenario ever happens, you should know that you’re providing Negative Value. Again, let’s try to remember that your peers are not out to get you, and can probably be trusted to be reasonable humans if you meet them mid-way.
With that framework in mind, it’s time that you demonstrate some trust, and Delegate to them. Give them access. Your value is not in the logon credentials that you have, otherwise you’re just a poorly-implemented “Terminal-as-a-Service”.
Even better than giving access, is giving Tooling. Logging into a server should be an antipattern for most work! You need some better tooling. So, with the example of logging, let’s talk tooling.
SysLog is better than nothing, but not by much. Shipping logs is easy, but consuming them as something useful is not. Batteries not included.
If your company wants to spend the money on Splunk, then encourage that. Splunk is a fantastic suite of tools, but I might wave you away from it if you’re not going to use it for everything. It’s going to be expensive, and if you’re not going to spend enough to use it for everything, there will be confusion as to what’s in there, and what’s stored elsewhere.
ELK (ElasticSearch + Logstash + Kibana, sometimes mistakenly simplified to “Logstash”), or a “Cloudy Elk” / “ELK-as-a-Service” is a good middle-ground. ELK is Free (as-in-beer), and very featureful.
Take your Centralized logging of choice, and provide your customers with the url to the web interface. Send them links to the “How to use” docs, and get out of their way!
If someone asks you to “run this command for me”, you need to put a button on it.
You don’t need to RUN-ALL-THE-THINGS!
Rundeck is a fantastic tool to “Put a button on it”. Other people use their CI tools (like Jenkins or Bamboo) for this. My friend Jeremy Price gave an Ignite Talk at DevOpsDays NYC 2015 that describes this.
Personally I like Rundeck, because it’s pretty easy to make HA, tie it into LDAP for credentials, manage permissions, and by shipping it’s logs (see what I did there?), you get Auditing of who ran what and when!
If you have some data that Must be restricted, try to isolate those cases from the rest of your environment. You shouldn’t have to restrict Everything just because Something does need isolation.
What if you make it easy for them to do it? Empower them with trust and tooling, making it easy to do the right thing! Give them tooling to see that the deploy succeeded! Logs are a start, but Metrics Dashboards that show changes in performance conditions and error rates will make it plain to see if a deployment was successful!
This Freedom doesn’t come free. Providing tooling doesn’t absolve the development teams of the need to communicate; in fact, it’s likely that they’ll have to communicate more. They will need to be watching those dashboards and logs to see for themselves the success of every deploy. They will also be more readily on-hand to help triage the inevitable instances when it doesn’t go swimmingly.
While that may sounds like some happy-go-lucky, tree-hugging, pop-psychological nonsense (and it is…:), the goal here is to get you, the beleaguered SysAdmin the help that you need, in order to improve the capabilities of the business.
The psychological damage done to SysAdmins by their peers can make us bitter and cynical. I encourage my people to try to see that “They” aren’t trying to make life difficult for you, but it’s very likely that Authority and Responsibility are misaligned. I likewise encourage my people to take steps to make their lives better. A ship’s course is changed in small degrees over time.
When someone says “DevOps Doesn’t Work”, they’re absolutely correct. DevOps is a concept, a philosophy, a professional movement based in trust and collaboration among teams, to align them to business needs. A concept doesn’t do work, and a philosophy does not meet goals - people do. I encourage you to seek out ways of working better with your fellow people.
Edited by Shaun Mouton (@sdmouton)
“DEVOPS DOESN’T WORK”
The number of times that I’ve heard this is amazing. The best thing about this phrase is that the people who say it are often completely right, even if for very wrong reasons.Who Says This?
Well, let’s talk about the people who most commonly have this reaction: SysAdmins. I’m going to use the term “SysAdmins” as a shorthand for a broad group. The people in this group have widely varying titles, but it is most commonly “Systems”, “Network”, or “Operations” follwed by “Administrator”, “Engineer”, “Technician”, or “Analyst”.In some companies, these folks have the best computers in the place. In others, they have to live with the worst. Their workspace probably isn’t very nice, and almost certainly has no natural light. If there is a pager rotation, they are almost certainly on it. If there isn’t a rotation, they’re basically on-call all of the time.
During the course of a normal day they might have to switch contexts between disaster planning, calculating power and HVAC needs for a new datacenter, scrambling to complete an outage-driven SAN migration, rushing to address urgent requests to help people with their email, to troubleshoot a printing problem, or suss out why someone can’t get to their electric company’s bill pay website. They may be the sole person with database expertise in the company, or they may work on a team of dozens.
The work is largely invisible except when something fails, in which case it’s highly visible and widely impacting.
These are typically cynical people, because there are only so many times that you can’t make the team/department/company party for ostensibly “celebrating our successes” because something’s broken, and you’re left to clean up after the “success”. There are only so many times that one sees a new project announced and begins to hire more people. When asked who’s going to support the new project, the response is a blank look and “you are”. The “…of course.” may not be vocalized, but it’s probably there. When asked how many people they get to hire to help with the workload, the response is a combination of “sorry, but there wasn’t anything left in the budget”, “it won’t be that much more work”, or a variation of the “team player / good soldier” speech. There are only so many times one can take getting your requests for training or conference budget rejected out of hand, and have your requests for training or conference budget laughed out of the room.
They probably have basic working knowledge of a half-dozen programming languages, but most likely they often think in Shell. They probably know at least three ways of testing if a port is open, and probably have a soft spot in their heart for a couple of shell commands.
They may have seen or participated in a DevOps initiative that consisted of a team or position rename, or helpfully suggested that they install some Config Management and Monitoring software so that “we can DevOps now…” or “so we can do Agile”. When they hear “DevOps” or “Agile”, what they are hearing is is Let’s take the same people who can’t handle a planned release schedule or make whatever effort that they need to squeak by the Change Board and Release Management requirements, and give them unfettered access to Production. Clearly, I’m not paged often enough.
So what is one to do? How is one to maintain their sanity in the face of increasing job scope, increasing demand for access and velocity, and little hope for an effective new-hire count? Not to mention continuing to juggle the existing volume of requests, and continuing to grease the existing gears to keep the machine running.
GET HELP
Please note that I’m not saying “just”. There’s nothing just about this situation; there is nothing simple about any of this, and Justice hasn’t been seen in a long time in an environment where this is the norm. Most of these changes are difficult. They will take work, and will require convincing other teams to join in your cause.
Admitting you have a Problem
The problem (probably) isn’t technical. It’s almost entirely social.Because SysAdmins are typically responsible for the environment, the easiest way to assure that the state is stable is to lock everyone else from it. While this helped with the goal of “keeping out unexpected changes”, it had a number of side effects.
First, a kind of learned helplessness has set in. Your customers and teammates became so used to being “hands-off”, that they don’t have the wherewithal to meet reasonable expectations. Since they’re uncomfortable making any changes, all changes must be made by the SysAdmins. This leads to your time being taken by having to perform lots of low-value tasks.
Some teams settle on the pattern of “hands off Production, but you have access to Staging”, but this is fraught with peril. The most common problem that stems from this is “Configuration Drift.” Config Drift is when you have different settings in one environment (or server) than the others. When the cost to discover what Production looks like is high, it’s more likely that people will either use defaults, make assumptions, or use the same configs that they use in their IDEs. “Works on my machine”, indeed.
This is a problem well-solved by Configuration Management tools, but you still need to be willing to trust your peers and give them access. If you want to be part of the process of validating changes, you could put in place the structures that allow a pull-request and code-review workflow, something that your Software Engineering peers should be very accustomed to! Granting access to see the existing configs and the ability to propose changes also shares responsibility for your team’s environments and contributes to feelings of ownership. Denying colleagues the ability to effect necessary configuration changes contributes to the root problems of configuration drift and learned helplessness.
Stop Feeding the Machine
Your value is not in doing the work, but rather being able to make the decision to do the work.I’ll be the first to say that “Automating ALL THE THINGS” is a flawed goal. At work, it’s usually said in the context of a Project, rather than part of a philosophy of Continual Improvement (Think Toyota Kata). You shouldn’t have to engage in an “Automation Project” to improve your environment. Build into your schedule time to solve one problem. Pick something that is rough, manual, and repeatable. Remove a small piece of friction. Move on to the next one. Hint: Logging into a server to make a configuration change should be a cue to implement configuration management!
While I agree that everything being automated, not everything should be automatic. Decision-making is complex, and attempting to codify all of the possible decision-making points is a fantastic way to make yourself insane. Not to mention that documenting your decision-making processes may be an unwanted look inside your brain. Caveat Implementor. (Or perhaps that’s just me…)
All of the units of work should be automated. But the decision to run the now-automated tasks can be left to a human. When you find that there is a correlation between steps, those pieces should be wrapped together. Automation isn’t a project into itself. It should be iterative. Pick something that’s painful. Make it a little smoother. Repeat. Ideally, you have time blocked out for Continuous Improvement. If not, create a meeting, or create a weekly project to do so. Review the issues that you’ve experienced lately, and pick something to make better. It might be worth making into a project, but it won’t be an ALL-THE-THINGS project. Create a scope of effort. Take the time to plan goals and requirements.
Whatever you don’t automate must be documented. Beyond the typical benefits of documentation, it also serves as “Functional Requirements” for someone else to pick up when they can help you with providing a solution. Try to recognize whether documenting or automating takes longer. Perhaps this piece of documentation will bet better served by “Executable Documentation” (i.e. code).
Clarify Your Role
You should attempt to pick apart the parts of your work, and attempt to describe them. One way to make this a fun exercise is to use other job titles to describe the work.
Are you an “Internet Plumber”? How much of your job could be described as “Spelunking” into the deep dark caverns of Legacy systems?
If you want, you could ascribe Superhero names to these parts of your work. The added bonus is that it not only describes a role, but also a demeanor associated with them. When ‘bad code’ makes it to Production, do you go “Wolverine” on that dev team?
Could you describe part of your role as “Production Customs Official”? Are you the gateway to Production? If so, are you actually equipped to do that? Here’s a quick test: When you say “no, that can’t go”, do you get overridden?
More importantly, is this what you want to do?
Prepwork
You will need to prepare for this. Most SysAdmin teams do not have a healthy relationship with the rest of the business. You will need to initiate the healing.Take someone to lunch. Preferably someone who you don’t know well. Ask questions, and listen to the answers. It is not time to defend yourself or your team. It’s time to find out what the business needs from someone else’s perspective. Ask what they think that your team’s role is in toward achieving that success. Ask what they think your team does well, and where there are gaps between what you have now and excellence.
Speak their language
You probably recognize their words, but you need to go out of your way to speak them. To communicate your message, you will need meet them on their turf. This may seem terribly unfair - “Why can’t they meet me on my terms?!” - but I’m guessing that has not been working out well for you so far.
Not only do you need to use their language, but you need to communicate over their medium. And identifying who they are is step one in learning to speak it. It’s probably not IRC, and only writing it in email is a good way for it to be ignored.
If you’re speaking to management, be prepared to write a presentation. Executives especially like to see a slide-deck. It doesn’t have to be slick. It probably shouldn’t have sounds or much in the way of transitions, but a presentation can help to lay the groundwork for a conversation.
Discuss Scope, Staffing, and Priorities
Now that you have described your role, we also need to describe everything that you support.
What Products do you support? It’s entirely possible (likely, even) that the people and teams that you support don’t actually know what you’re responsible for. It could be argued that most of them shouldn’t need to know. But if you have been saying “no” to protect yourself, it’s a sign that you are significantly overextended. You need to have a real discussion with your leadership about your role, scope, and staffing.
In order to have this discussion, you need to prepare. You need to come up with a fairly comprehensive list of the products and teams that you support. This is a list of every team, and their products, the components and tasks that belong to you for each. Don’t forget all of the components that “nobody owns” but somehow people come to you to fix or implement (CI, SCM, Ticketing, Project, and Wiki tools seem to be common examples). Are you also responsible for Directory Services? Virtualization platform? Mail/Chat/Phones? Workstation Purchasing and provisioning? Printers? Do you manage the Storage, Networking, etc? Don’t be afraid of getting into details. It can help to provide clearly written potential impacts the company if some of these “hidden” services stop working? Your leadership might not know what LDAP or Directory Services are, but they’ll understand if nobody can log into their machines, they can’t pull information to build reports, and by-the-way nobody can deploy code because it relies on validating credentials…
What is most important to the company? What do you need to succeed? How much more staff do you need? What tooling or equipment would help you work more efficiently? Does code deploy even when it fails testing? How many outages have arisen due to this happening?
Demonstrate Cost and Value and Revisit Priorities
In order to have meaningful discussions with people in your company who aren’t necessarily technical, you need to be able to relate to a language that they speak. Regardless of team duties, the lingua franca of most teams is money. As Engineers, most of us prefer to think in terms of the tech itself, but in order to describe an impact, a unit of monetary value is a proxy for impact that most non-technical people can understand, even if they don’t grasp the details.It is a helpful (if difficult and uncomfortable) habit to get into, but I encourage you to consider the components of cost that goes into every incident or task.
What is the cost of a main-site outage? How much revenue does this feature bring in? Why are you spending so much on infrastructure and effort to make that component Highly-Available? Why does it matter that you do that piece of maintenance? Show the negative value of doing things they way they are (Opportunity Cost), versus investing time to improve the automation around it. Describe how doing this maintenance work reduces your context switching, unplanned outages, and lost reputation of your company. Describe the benefit in increased visibility to the business, and Agency to be gained by your peers on other teams.
Why put in place these tools to let product teams self-serve? Describe that the features that the company’s teams spend so much time and effort (read: “money”) creating means nothing if those features aren’t available for customers to use. That having those features not available costs money in terms of feature billing, and reputation cost. If they claim that they’re doing Agile, but can’t do Continuous Delivery, they’re not really Agile, and the whole point of that framework is to improve delivery of value to the customer and the business!
Further, show how systems relate. It doesn’t have to be terribly detailed. Describe that the features that the customers use are reliant on x, y, and z components of infrastructure. Draw the lines from LDAP to storage to your CI tool to testing code to artifacts delivered to Production. Then show some of the other systems that have similar dependencies.
Once the picture emerges showing how everything is reliant on unexciting things like LDAP, your Storage cluster, and that janky collection of angry shell and perl scripts that keep everything working, realization will begin to dawn.
Congratulations, you’ve just effectively communicated Value.
Align Responsibility with Authority
Are you held responsible for apps written by other people? Who gets paged when “the app” goes down? How does that make sense?Get Devs on-call for their apps. SysAdmins should be escalated to. Devs can triage and troubleshoot their own apps more readily than you can. They get to call in the cavalry when they get stuck. They don’t need to know everything about the systems, and they don’t need to resolve everything. When a fault occurs and they need help, they stay on the call, pairing with you as you diagnose, troubleshoot, and resolve. That way, they don’t need to escalate to you for that thing the next time it occurs, and can collaborate on automating a permanent fix.
When teams aren’t responsible for their products - When they aren’t paged when it fails - they are numb to the pain that they inflict. They’re not trying to cause pain; they just don’t feel it. It’s especially easy to argue this for teams that proclaim that they use Agile development methods: If they claim to want “continuous feedback”, there is nothing more visceral for providing feedback than the feeling of being awoken by a pager in the middle of the night. When the inevitable exclamation comes that “we can’t interrupt our developers”, ask if it makes sense to interrupt someone else.
Even being aware of the pain (say, hearing how many times you were paged last night) can elicit sympathy, but that’s a far cry from the experience of being paged yourself.
Further, this is what that list of responsibilities is for. Asking each team to take responsibly for their own products, you will still likely have a hefty list of services that you provide that you are on-call for. As these set in, point out the staffing numbers. This may be a matter of the places that I have worked, but I have never seen a Developer-to-SysAdmin ratio of less than 5-1. In most places it is much higher. By adding these teams to pager rotations, they drastically reduce the load on you. By not adding them to pager rotations, they are complicit in your burnout.
Stop saying “No”
SysAdmins have a reputation for saying “No”. The people who are asking are probably not trying to make your life worse; They’re probably just trying to get their work done. They might not know what their “simple request” involves, and that it probably isn’t necessary.But by not having Responsibility aligned with Authority, you may have been stuck with the pain of other people’s wishes. You know that fulfilling their request will cause you pain, so understandably, you say “no”. What often happens next is that they escalate until they hit someone sufficiently important enough to override you.
This is the basis for why SysAdmins feel steamrolled by everyone else, and everyone else feels held hostage by SysAdmins.
But all hope is not lost.
Stop saying “No”.
“Yes, but …” is a very powerful thing.
“Yes, but …” can be used to get you help.
“Yes, I can set that up for you, but we don’t have capacity to run it for you.” What happened there? You agreed that the request is reasonable. You set expectations of the level of support that you can give. You left the requestor with several options to continue the conversation.
- They might have hiring reqs that they can’t fill. You can negotiate for some of them to go to your team, as you’re clearly understaffed.
- Some of their engineers may join your team as a lateral move. They’ll need mentorship and training, but this kind of cross-training is invaluable. It’s a force multiplier. It also sets precedent.
- They might take the responsibility for the Thing. They run it. They get paged for it. Of course you will probably have to be an escalation point to assist when it fails, but it’s their product. This again sets precedent.
Delegate
Most SysAdmins are stuck doing tasks that provide very little value because they restrict access to their peers. To my mind, there is one perfect example: “Playing Telephone”.When I say “Playing Telephone”, I’m talking about the situation where someone (let’s say a Developer) wants logs from the application, but they don’t have access to get them. They request the logs from you. You fetch the log requested and provide it to them. “No, not that log, this log…” You fetch. “Hmm, I’m not seeing what I’m looking for, could you check in here for something that says something like this …?” And so on, and so on…
I don’t know what you’re hoping to prevent by restricting access, but if this scenario ever happens, you should know that you’re providing Negative Value. Again, let’s try to remember that your peers are not out to get you, and can probably be trusted to be reasonable humans if you meet them mid-way.
With that framework in mind, it’s time that you demonstrate some trust, and Delegate to them. Give them access. Your value is not in the logon credentials that you have, otherwise you’re just a poorly-implemented “Terminal-as-a-Service”.
Even better than giving access, is giving Tooling. Logging into a server should be an antipattern for most work! You need some better tooling. So, with the example of logging, let’s talk tooling.
Logging
First, logging into boxes to get logs is just dumb. Sure, you could wrap atail command in a Rundeck job, but let’s Centralize those logs while we’re at it.SysLog is better than nothing, but not by much. Shipping logs is easy, but consuming them as something useful is not. Batteries not included.
If your company wants to spend the money on Splunk, then encourage that. Splunk is a fantastic suite of tools, but I might wave you away from it if you’re not going to use it for everything. It’s going to be expensive, and if you’re not going to spend enough to use it for everything, there will be confusion as to what’s in there, and what’s stored elsewhere.
ELK (ElasticSearch + Logstash + Kibana, sometimes mistakenly simplified to “Logstash”), or a “Cloudy Elk” / “ELK-as-a-Service” is a good middle-ground. ELK is Free (as-in-beer), and very featureful.
Take your Centralized logging of choice, and provide your customers with the url to the web interface. Send them links to the “How to use” docs, and get out of their way!
Terminal-as-a-Service
If someone asks you to “run this command for me”, you need to put a button on it.You don’t need to RUN-ALL-THE-THINGS!
Rundeck is a fantastic tool to “Put a button on it”. Other people use their CI tools (like Jenkins or Bamboo) for this. My friend Jeremy Price gave an Ignite Talk at DevOpsDays NYC 2015 that describes this.
Personally I like Rundeck, because it’s pretty easy to make HA, tie it into LDAP for credentials, manage permissions, and by shipping it’s logs (see what I did there?), you get Auditing of who ran what and when!
If you have some data that Must be restricted, try to isolate those cases from the rest of your environment. You shouldn’t have to restrict Everything just because Something does need isolation.
Deploying Code. Yes, to Production
Why would you want to have to deploy other people’s code?! Do you really provide any value in that activity? If the deployment doesn’t go well, you’re launching another game of “Telephone”.What if you make it easy for them to do it? Empower them with trust and tooling, making it easy to do the right thing! Give them tooling to see that the deploy succeeded! Logs are a start, but Metrics Dashboards that show changes in performance conditions and error rates will make it plain to see if a deployment was successful!
This Freedom doesn’t come free. Providing tooling doesn’t absolve the development teams of the need to communicate; in fact, it’s likely that they’ll have to communicate more. They will need to be watching those dashboards and logs to see for themselves the success of every deploy. They will also be more readily on-hand to help triage the inevitable instances when it doesn’t go swimmingly.
US
I say “They” in this article a lot. And that is because, by default, most organizations that I have been a part of or heard stories of have had a strong component of “Us-Versus-Them.” It’s only natural for there to be an “Us” and a “Them”, but thinking in those terms should be a very short-term use of the language. Strive for the goal of a “We” in your interactions at work, and reinforce that language wherever possible. While it may not be My job to do “foo”, it is Our job to ensure the team and company is successful.While that may sounds like some happy-go-lucky, tree-hugging, pop-psychological nonsense (and it is…:), the goal here is to get you, the beleaguered SysAdmin the help that you need, in order to improve the capabilities of the business.
CODA
There is so much more to this topic, particularly the shift away from a Systems team supporting a bunch of Project teams to a series of largely self-sustaining Product teams, but that will have to wait for another day.The psychological damage done to SysAdmins by their peers can make us bitter and cynical. I encourage my people to try to see that “They” aren’t trying to make life difficult for you, but it’s very likely that Authority and Responsibility are misaligned. I likewise encourage my people to take steps to make their lives better. A ship’s course is changed in small degrees over time.
When someone says “DevOps Doesn’t Work”, they’re absolutely correct. DevOps is a concept, a philosophy, a professional movement based in trust and collaboration among teams, to align them to business needs. A concept doesn’t do work, and a philosophy does not meet goals - people do. I encourage you to seek out ways of working better with your fellow people.
GRATITUDE
I’d like to thank my friends for listening to me rant, and my editor Shaun Mouton for their help bringing this article together. I’d also like to thank the SysAdvent team for putting in the effort that keeps this fun tradition going.CONTACT ME
If you wish to discuss with me further, please feel free to reach out to me. I am gwaldo on Twitter and Gmail/Hangouts, and seldom refuse hugs (or offers of beverage and company) at conferences. Death Threats and unpleasantness beyond the realm of constructive Criticism may be sent to:
Waldo
c/o FBI Headquarters
935 Pennsylvania Avenue, NW
Washington, D.C.
20535-0001
2015-12-15
On SysAdvent 2015
Knowing that I'd regret it if I didn't, I took on yet another task, and wrote a thing for SysAdvent.
"Fear and Loathing in Systems Administration"
This is a title that I'd had kicking around in my head for awhile, and have started shopping it around as a conference talk. I'm hoping to get some feedback on the article content in order to tweak the presentation content.
"Fear and Loathing in Systems Administration"
This is a title that I'd had kicking around in my head for awhile, and have started shopping it around as a conference talk. I'm hoping to get some feedback on the article content in order to tweak the presentation content.
2014-07-02
On Raymond Ramos
I want to talk about my friend Raymond Ramos. My friend is dead. He's been dead for nine years, and I still miss him.
One night while deployed to Iraq, I found myself "on duty". At this particular instance, my duty was to inflate the ego of the CO and SgtMaj, and relay useful news to anyone who happened by the desk. While armed. In theory, if Al Qaeda came by, it was my job to kill them, but in reality there was no way for them to not have the jump on me, and the best that I could do is die a loud death. Even in Iraq, Egos must be stroked. And they were.
While I sat bored, uncomfortable, and awaiting zealous but non-specific rage (or a passing ego), someone who knew both of us told me that Ray had died. My friend, who had been honorably discharged months earlier, had died in Alabama while traveling for a job interview. My assistant took over the watch, as I walked away in tears.
He had made it through his enlistment. He was supposed to have been safe. That's probably what had hit me the hardest; "unsafe" was a deployment to a hotspot, or a mission. "Unsafe" meant armed, briefed, and geared-up. He was supposed to have been safe. He made it through his enlistment intact. Game over, you win, enter initials.
Nope. See, "unsafe" is a sliding scale. While I was on the far side of the scale (but not all the way over), in my mind, he was swaddled safe in civilian life.
While our CO was a raving asshole (which contrary to public image, is absolutely not normal), he did say exactly one useful thing when we landed in-theatre. I don't recall exactly what he said, but what I absorbed is this: "Death can be a lightning strike on a clear day. It can come at any time, from any direction. When it's your time, there's nothing to do about it."
I'd absorbed this for myself, and my friends and colleagues in-theatre. But Ray had been safe.
I never got an official story, but this is what I recall being told. Ray had been driving for a job interview, and lost control of his car, went off the road, and was severely injured. I seem to remember that he'd left messages for his girlfriend, but she didn't get them until he had died. I wonder if he didn't have cell reception, and just left voice memos. As I'd heard it, the last one (possibly the third), he was resigned to death, and said goodbye.
When a Marine departs a unit (whether a change of duty or when leaving service), it is customary - at least for those in good standing - to receive a plaque commemorating their service. Naturally, the more rank that one has, the more extravagent the plaque. Those who won't be missed get something generic, but a good plaque is apparent. Ray was Corporal when he got out. He may have picked up Sergeant right before he got out, but it would have been on his way out.
Normally there is a collection is taken from among everyone in a given unit for a given Marine's plaque. You pay into each plaque as one of the best and most direct examples of "paying it forward" that there is in this world. Plaques usually come from a local awards company (where you'd go have bowling trophies made), and the standard no-effort plaque has the Marine's name and dates with the unit, and the unit logo. Perhaps a motivational phrase or a quote that the Marine was fond of saying.
Now, Ray wasn't what you could call a "Marine's Marine." He wasn't "hard-core" or "gung-ho", or any of that bullshit. You couldn't imagine him shouting "Let's take that fucking hill" outside of a joke. In fact, Ray's demeanor could be said to piss some people off; Sergeants Major either loved him or hated him. You could reliably predict how much a given Staff NCO would like him based on how comfortable they were with technology newer than, say, the typical ballpoint pen. If they were the kind to send a "runner" than a email, they hated him; if they theoretically knew the difference between "Reply" and "Reply All", they probably loved him. (NOTE: Senior Staff NCOs are very rarely more savvy than this.)
No, Ray was never going to win a "Marine / NCO of the Quarter" board. He didn't really know Marine Corps history. He knew the day-to-day customs & courtesy, but not much beyond that. He shuffled when he walked, and never re-soled his boots, so much so that he and a few of our friends referred to them as his "Combat Slippers"; it didn't help that they weren't polished, and were only barely what you could describe as "black". His uniform looked like it had once met an iron, but they weren't more than casual acquantences. This was very foreign to me coming from an occupational field that was very starch-and-polish, as well as dirty-in-the-field; I was used to being one or the other.
Please keep in mind that this was circa-2004. Google was around, but not in common use yet. Technet and MSDN were around, but search sucked, and information was categorized. (Which meant invariably that the taxonomy made sense, but not to you.) There was no Stack Overflow. While Windows XP/2003 were out, most of our domains were NT, groupware was Exchange 5.5, and workstations were either NT or 2000. The only Unix was in the specialized Intelligence boxes, and I was probably one of 10 people on the base who'd even installed Linux. This is what we had.
Ray and I were SysAdmins. SysAdmins in the Marine Corps don't code. Programmers code, and SysAdmins aren't Programmers. Being a Programmer in the Marine Corps means that you will be spending 80% of your time working on the CO's Pet Project, which is usually some stupid website that nobody will really use and won't survive your departure. The consequence of this is that the work that you should be doing falls to your compatriots, who are few in the first place, and already barely keeping things afloat.
But he had this insatiable curiosity, and this provided a great intellectual focus for him. Unfortunately the big boss found out, and the next thing you knew, a Pandora's Box of pet projects exploded in our office.
So, one day Ray's hacking on something like a CMS for shit nobody cares about, or an in-browser chat client, and he's pondering. Pondering hard. "How can I....?" I don'
t remember if he exclaimed "EUREEKA!", but it might as well have been. Next comes "I KNOW! I'LL DO IT WITH A COOKIE!" This was the first time I'd seen demonstrated the pure joy that comes when a solution presents itself.
So, when it came time for him to leave, knowing that the unit would get him something generic, I took care of it. I wanted him to have something special.
Ray loved him some Star Trek. Original, Next Generation, whatever. So, I went to a hobby shop, picked up a roughly 10" version of NCC-1701, assembed, painted, and decaled it. I took it into the awards shop with an idea and a quote, and they said "no problem."
While the quote that Ray was most fond of was to reply to statements with "...But does that make it right?", what I had inscribed on his plaque was "I'll do it with a Cookie!"
A going-away party in the Marine Corps can range from a don't-let-the-door-hit-you-on-the-ass-on-the-way-out just about all the way through a weekend-long Roman orgy of an alcohol-and-grilling bender. Most of the time, it's making sure that your immediate office and some unit friends have lunch before you leave. Often it's with said Marine's car packed, and they're about to drive off base for the last time.
Ray's going-away party was a lunch at El Cerro Grande, the local Mexican establishment. We had a pretty good turnout. There were stories told, and a few last-minute items he'd forgotten. After the food and nostalgia finished, and the awkward and anxious quiet settled, some of us gave mini-speeches. MSgts Brown and Ayo said something, and they turned it over to me. I said a few things, reflecting on our past few years. Then I presented his plaque.
He cried and hugged me. I cried.
This is how I remember my friend Ray.
Ray indirectly taught me much more important things than he directly taught me. The most useful to my life and career is that being autodidactic is very useful. Being able to state a problem, ask an actionable question, and research an answer is amazingly useful. He also taught me that Programming is not (necessarily) evil, and formal training is not required to learn it.
Let us end with a toast. "To Absent Friends..."
-Waldo
One night while deployed to Iraq, I found myself "on duty". At this particular instance, my duty was to inflate the ego of the CO and SgtMaj, and relay useful news to anyone who happened by the desk. While armed. In theory, if Al Qaeda came by, it was my job to kill them, but in reality there was no way for them to not have the jump on me, and the best that I could do is die a loud death. Even in Iraq, Egos must be stroked. And they were.
While I sat bored, uncomfortable, and awaiting zealous but non-specific rage (or a passing ego), someone who knew both of us told me that Ray had died. My friend, who had been honorably discharged months earlier, had died in Alabama while traveling for a job interview. My assistant took over the watch, as I walked away in tears.
He had made it through his enlistment. He was supposed to have been safe. That's probably what had hit me the hardest; "unsafe" was a deployment to a hotspot, or a mission. "Unsafe" meant armed, briefed, and geared-up. He was supposed to have been safe. He made it through his enlistment intact. Game over, you win, enter initials.
Nope. See, "unsafe" is a sliding scale. While I was on the far side of the scale (but not all the way over), in my mind, he was swaddled safe in civilian life.
While our CO was a raving asshole (which contrary to public image, is absolutely not normal), he did say exactly one useful thing when we landed in-theatre. I don't recall exactly what he said, but what I absorbed is this: "Death can be a lightning strike on a clear day. It can come at any time, from any direction. When it's your time, there's nothing to do about it."
I'd absorbed this for myself, and my friends and colleagues in-theatre. But Ray had been safe.
I never got an official story, but this is what I recall being told. Ray had been driving for a job interview, and lost control of his car, went off the road, and was severely injured. I seem to remember that he'd left messages for his girlfriend, but she didn't get them until he had died. I wonder if he didn't have cell reception, and just left voice memos. As I'd heard it, the last one (possibly the third), he was resigned to death, and said goodbye.
When a Marine departs a unit (whether a change of duty or when leaving service), it is customary - at least for those in good standing - to receive a plaque commemorating their service. Naturally, the more rank that one has, the more extravagent the plaque. Those who won't be missed get something generic, but a good plaque is apparent. Ray was Corporal when he got out. He may have picked up Sergeant right before he got out, but it would have been on his way out.
Normally there is a collection is taken from among everyone in a given unit for a given Marine's plaque. You pay into each plaque as one of the best and most direct examples of "paying it forward" that there is in this world. Plaques usually come from a local awards company (where you'd go have bowling trophies made), and the standard no-effort plaque has the Marine's name and dates with the unit, and the unit logo. Perhaps a motivational phrase or a quote that the Marine was fond of saying.
Now, Ray wasn't what you could call a "Marine's Marine." He wasn't "hard-core" or "gung-ho", or any of that bullshit. You couldn't imagine him shouting "Let's take that fucking hill" outside of a joke. In fact, Ray's demeanor could be said to piss some people off; Sergeants Major either loved him or hated him. You could reliably predict how much a given Staff NCO would like him based on how comfortable they were with technology newer than, say, the typical ballpoint pen. If they were the kind to send a "runner" than a email, they hated him; if they theoretically knew the difference between "Reply" and "Reply All", they probably loved him. (NOTE: Senior Staff NCOs are very rarely more savvy than this.)
No, Ray was never going to win a "Marine / NCO of the Quarter" board. He didn't really know Marine Corps history. He knew the day-to-day customs & courtesy, but not much beyond that. He shuffled when he walked, and never re-soled his boots, so much so that he and a few of our friends referred to them as his "Combat Slippers"; it didn't help that they weren't polished, and were only barely what you could describe as "black". His uniform looked like it had once met an iron, but they weren't more than casual acquantences. This was very foreign to me coming from an occupational field that was very starch-and-polish, as well as dirty-in-the-field; I was used to being one or the other.
Please keep in mind that this was circa-2004. Google was around, but not in common use yet. Technet and MSDN were around, but search sucked, and information was categorized. (Which meant invariably that the taxonomy made sense, but not to you.) There was no Stack Overflow. While Windows XP/2003 were out, most of our domains were NT, groupware was Exchange 5.5, and workstations were either NT or 2000. The only Unix was in the specialized Intelligence boxes, and I was probably one of 10 people on the base who'd even installed Linux. This is what we had.
Ray and I were SysAdmins. SysAdmins in the Marine Corps don't code. Programmers code, and SysAdmins aren't Programmers. Being a Programmer in the Marine Corps means that you will be spending 80% of your time working on the CO's Pet Project, which is usually some stupid website that nobody will really use and won't survive your departure. The consequence of this is that the work that you should be doing falls to your compatriots, who are few in the first place, and already barely keeping things afloat.
But he had this insatiable curiosity, and this provided a great intellectual focus for him. Unfortunately the big boss found out, and the next thing you knew, a Pandora's Box of pet projects exploded in our office.
So, one day Ray's hacking on something like a CMS for shit nobody cares about, or an in-browser chat client, and he's pondering. Pondering hard. "How can I....?" I don'
t remember if he exclaimed "EUREEKA!", but it might as well have been. Next comes "I KNOW! I'LL DO IT WITH A COOKIE!" This was the first time I'd seen demonstrated the pure joy that comes when a solution presents itself.
So, when it came time for him to leave, knowing that the unit would get him something generic, I took care of it. I wanted him to have something special.
Ray loved him some Star Trek. Original, Next Generation, whatever. So, I went to a hobby shop, picked up a roughly 10" version of NCC-1701, assembed, painted, and decaled it. I took it into the awards shop with an idea and a quote, and they said "no problem."
While the quote that Ray was most fond of was to reply to statements with "...But does that make it right?", what I had inscribed on his plaque was "I'll do it with a Cookie!"
A going-away party in the Marine Corps can range from a don't-let-the-door-hit-you-on-the-ass-on-the-way-out just about all the way through a weekend-long Roman orgy of an alcohol-and-grilling bender. Most of the time, it's making sure that your immediate office and some unit friends have lunch before you leave. Often it's with said Marine's car packed, and they're about to drive off base for the last time.
Ray's going-away party was a lunch at El Cerro Grande, the local Mexican establishment. We had a pretty good turnout. There were stories told, and a few last-minute items he'd forgotten. After the food and nostalgia finished, and the awkward and anxious quiet settled, some of us gave mini-speeches. MSgts Brown and Ayo said something, and they turned it over to me. I said a few things, reflecting on our past few years. Then I presented his plaque.
He cried and hugged me. I cried.
This is how I remember my friend Ray.
Ray indirectly taught me much more important things than he directly taught me. The most useful to my life and career is that being autodidactic is very useful. Being able to state a problem, ask an actionable question, and research an answer is amazingly useful. He also taught me that Programming is not (necessarily) evil, and formal training is not required to learn it.
Let us end with a toast. "To Absent Friends..."
-Waldo
2014-02-18
Cooking for Geeks - A Review
It seems that most of the writing that I've been doing is reviews. Fortunately I have plenty of articles to write in my head, but the times that I feel like writing are pretty inopportune (such as my commute.)
So, dear friend, we have another review of an O'Reilly book, and providing full disclosure, I received a free copy of this book in exchange for a review... All integrity accountability in-place, let us begin.
Chapter 1 opens with the headline "We geeks are fascinated by how things work, and most of us eat, too." This book makes it very plain that it is a book for geeks (who want to learn more about the alchemy that is cooking), by geeks (who know some things about said alchemy).
While I already have a basic competency in the kitchen, there was a lot of value for me in this book, even beyond the underlying explanations of "how" and "why".
One of the things that I appreciate most are the quick hacks to improve your life. Probably my favorite is the Pizza Stone tip. The tip is to keep your pizza stone in your oven; it will take longer for your oven to come up to temperature, but the stone will help to keep the temperature more even.
Probably the greatest value from this book is in technique. Rather than just a list of steps, there is a lot of explaination of "how" to do something as well as "why". Even though I have some experience cooking, I do appreciate that the assumption is that the reader is a thorough beginner.
All in all, I found this book to be pretty fun and very informative. I've already recommended it to others, and do so without reservation.
The book's website is http://www.cookingforgeeks.com/, and it can be purchased from Amazon, orfrom the publisher here.
-Waldo
So, dear friend, we have another review of an O'Reilly book, and providing full disclosure, I received a free copy of this book in exchange for a review... All integrity accountability in-place, let us begin.
Chapter 1 opens with the headline "We geeks are fascinated by how things work, and most of us eat, too." This book makes it very plain that it is a book for geeks (who want to learn more about the alchemy that is cooking), by geeks (who know some things about said alchemy).
While I already have a basic competency in the kitchen, there was a lot of value for me in this book, even beyond the underlying explanations of "how" and "why".
One of the things that I appreciate most are the quick hacks to improve your life. Probably my favorite is the Pizza Stone tip. The tip is to keep your pizza stone in your oven; it will take longer for your oven to come up to temperature, but the stone will help to keep the temperature more even.
Probably the greatest value from this book is in technique. Rather than just a list of steps, there is a lot of explaination of "how" to do something as well as "why". Even though I have some experience cooking, I do appreciate that the assumption is that the reader is a thorough beginner.
All in all, I found this book to be pretty fun and very informative. I've already recommended it to others, and do so without reservation.
The book's website is http://www.cookingforgeeks.com/, and it can be purchased from Amazon, orfrom the publisher here.
-Waldo
2014-01-27
On Hoodies
I have yet to find the perfect hoodie. Unlike the perfect knife, I am surprised at this, because it doesn't seem like it should be that hard.
This may come as a surprise, but I've only recently come to appreciate Hoodies. I can only think of one that I'd had during my youth that I didn't particularly care for, and didn't have any during my time in the Corps.
Perhaps they've only now come into my life because my office is in an unheated basement, or perhaps it's that my last few jobs have allowed for more casual attire. In any case, as is natural for me, now that I've experienced a thing, I have opinions on the matter.
The most obvious is the question of Zippered or Pull-Over. This one is actually pretty easy for me. While I appreciate the decorability and unified front pocket of a pull-over, the flexibility of partial-openness (as well as lower static generation) make me a Zippered man.
The one Pull-Over hoodie that I have has one flaw that is unique to it's shape that causes me annoyance, and that is that the neck hole is too small. I may have a large head and neck, but I'm surprised that the hole is as small as it is. It's small enough that it's hard to pull my head through the hole, and the neck sits uncomfortably close on my neck. I may need to go so far as to cut the neck to extend it, but then I'll have to do some sewing to keep it from ripping further.
So as far as Zippered Hoodies go, there is a feature that is unique to them that deserves attention when looking for the ideal hoodie. The zipper border - the piping of the garment material outside of the zipper itself - should be large enough that it covers the zipper teeth when closed. One of my hoodies, which I like despite it's two significant flaws, has an almost completely exposed zipper. It doesn't bother me in the normal wearing of the thing, but I am incredibly aware of it when resting something on my chest or stomach, such as a tablet, laptop, or handheld game. At times like this, I can feel the device scraping against the zipper, and it's all the more annoying because it seems like a completely unnecessary oversight.
Next are the features that are of crucial importance to me, but aren't specific to either style of hoodie.
The pockets should be large enough to fit my hands in to the wrist, and even better, fit a largeish handheld game system (Nintendo DS XL or 3DS XL) completely, parallel to the ground. If the pockets aren't big enough to do that, they're too small. Additionally, and have raised sides so that it's rare that anything (such as a DS XL) could fall out accidentally. Surprisingly, I don't have any that fail at this.
The sleeves are something that I wouldn't have expected to be an item of consideration, but alas, here I am writing... The material of the sleeve should have ample room for at least the average man. My arms are not by any definition "large", but one of my hoodies has sleeves that only barely fit. This is only compounded by the next feature of the sleeves: the cuffs.
The cuffs should be - I would have thought this would go without saying, but then again, here we are - *elastic*. And not just a little elastic; I should be able to push them up to my elbow, and have them stay there. I don't know when or why I started doing this, but when I'm doing work, if I'm wearing long sleeves, they're probably at least half-way up my forearm. When I'm passively consuming information or media, they may be down to the wrists, but when I'm producing, my sleeves are probably up. This is my own bias and habit, but it is still a thing for me: Why someone would make comfort-wear without comfortable sleeves is completely beyond me.
Finally, the hood. It should go without saying that the main job of a hoodie is to be a sweatshirt, but with-a-hood. So, you could reasonably be expected that a sweatshirt pattern and material with a decently-sized hood would be pretty easy to come up with. Alas, here I am... A hood should be much larger than the head wearing it. In my opinion, I should be able to pull my hood up, with my head all the way to the back of it, and it should come down to just over my eyes, and be loose around the sides of my head. What we're talking about is the Sith-look. Unfortunately, most of my hoodies' hoods barely come up to frame my face. That makes me sad. They had one job to do that made them different from a sweatshirt, and they failed.
Most of my hoodies actually fail at the hood. In fact, the features that I've complained about in each of the last several sections all refer to the same hoodie. Amazingly, it isn't my worst hoodie. Due to an absolutely awesome hood, I love that one, but it's a strange love; it's a love of the best of mediocrity. If I could find a hoodie that was good at all of these, I'd buy 10 of them and probably give most of the rest away.
This may come as a surprise, but I've only recently come to appreciate Hoodies. I can only think of one that I'd had during my youth that I didn't particularly care for, and didn't have any during my time in the Corps.
Perhaps they've only now come into my life because my office is in an unheated basement, or perhaps it's that my last few jobs have allowed for more casual attire. In any case, as is natural for me, now that I've experienced a thing, I have opinions on the matter.
The most obvious is the question of Zippered or Pull-Over. This one is actually pretty easy for me. While I appreciate the decorability and unified front pocket of a pull-over, the flexibility of partial-openness (as well as lower static generation) make me a Zippered man.
The one Pull-Over hoodie that I have has one flaw that is unique to it's shape that causes me annoyance, and that is that the neck hole is too small. I may have a large head and neck, but I'm surprised that the hole is as small as it is. It's small enough that it's hard to pull my head through the hole, and the neck sits uncomfortably close on my neck. I may need to go so far as to cut the neck to extend it, but then I'll have to do some sewing to keep it from ripping further.
So as far as Zippered Hoodies go, there is a feature that is unique to them that deserves attention when looking for the ideal hoodie. The zipper border - the piping of the garment material outside of the zipper itself - should be large enough that it covers the zipper teeth when closed. One of my hoodies, which I like despite it's two significant flaws, has an almost completely exposed zipper. It doesn't bother me in the normal wearing of the thing, but I am incredibly aware of it when resting something on my chest or stomach, such as a tablet, laptop, or handheld game. At times like this, I can feel the device scraping against the zipper, and it's all the more annoying because it seems like a completely unnecessary oversight.
Next are the features that are of crucial importance to me, but aren't specific to either style of hoodie.
The pockets should be large enough to fit my hands in to the wrist, and even better, fit a largeish handheld game system (Nintendo DS XL or 3DS XL) completely, parallel to the ground. If the pockets aren't big enough to do that, they're too small. Additionally, and have raised sides so that it's rare that anything (such as a DS XL) could fall out accidentally. Surprisingly, I don't have any that fail at this.
The sleeves are something that I wouldn't have expected to be an item of consideration, but alas, here I am writing... The material of the sleeve should have ample room for at least the average man. My arms are not by any definition "large", but one of my hoodies has sleeves that only barely fit. This is only compounded by the next feature of the sleeves: the cuffs.
The cuffs should be - I would have thought this would go without saying, but then again, here we are - *elastic*. And not just a little elastic; I should be able to push them up to my elbow, and have them stay there. I don't know when or why I started doing this, but when I'm doing work, if I'm wearing long sleeves, they're probably at least half-way up my forearm. When I'm passively consuming information or media, they may be down to the wrists, but when I'm producing, my sleeves are probably up. This is my own bias and habit, but it is still a thing for me: Why someone would make comfort-wear without comfortable sleeves is completely beyond me.
Finally, the hood. It should go without saying that the main job of a hoodie is to be a sweatshirt, but with-a-hood. So, you could reasonably be expected that a sweatshirt pattern and material with a decently-sized hood would be pretty easy to come up with. Alas, here I am... A hood should be much larger than the head wearing it. In my opinion, I should be able to pull my hood up, with my head all the way to the back of it, and it should come down to just over my eyes, and be loose around the sides of my head. What we're talking about is the Sith-look. Unfortunately, most of my hoodies' hoods barely come up to frame my face. That makes me sad. They had one job to do that made them different from a sweatshirt, and they failed.
Most of my hoodies actually fail at the hood. In fact, the features that I've complained about in each of the last several sections all refer to the same hoodie. Amazingly, it isn't my worst hoodie. Due to an absolutely awesome hood, I love that one, but it's a strange love; it's a love of the best of mediocrity. If I could find a hoodie that was good at all of these, I'd buy 10 of them and probably give most of the rest away.
2014-01-14
On Cultural Norms and Perception
At both my last gig and the current one, coffee was available via a Keurig.
At the previous gig, it was declared that you should remove your used cup when your brew was done, and if the reservoir was empty, you were to fill it. There were some people who seldom (if ever) did this, and there was much snark and gnashing of teeth.
At the current gig, we do the opposite: When you open the cup holder, you will have to remove the previous person's cup, and if the water is empty, you will have to fill the reservoir. You do these things because you are incentivized to do so, as either condition is a barrier to you getting your drink. As a result, there is no grousing or emotion aside from perhaps being briefly delayed.
In the former, a lazy person has caused you more work. In the latter, the worst-case is that you lose a trivial lottery.
I think the second way is better.
At the previous gig, it was declared that you should remove your used cup when your brew was done, and if the reservoir was empty, you were to fill it. There were some people who seldom (if ever) did this, and there was much snark and gnashing of teeth.
At the current gig, we do the opposite: When you open the cup holder, you will have to remove the previous person's cup, and if the water is empty, you will have to fill the reservoir. You do these things because you are incentivized to do so, as either condition is a barrier to you getting your drink. As a result, there is no grousing or emotion aside from perhaps being briefly delayed.
In the former, a lazy person has caused you more work. In the latter, the worst-case is that you lose a trivial lottery.
I think the second way is better.
2013-12-01
The Macintosh Terminal Pocket Guide - A Review
The Macintosh Terminal Pocket Guide - A Review
Disclosure: I received a free copy of this ebook in exchange for a review.
The "Macintosh Terminal Pocket Guide" by Daniel J. Barrett (published by O'Reilly Media) is a handy quick-reference for leveraging the power of the terminal to use your Mac more efficiently. This book is especially helpful for guiding you through the use of commands that are built-in with your Mac, which may vary from other Unix-like distributions that you may be more familiar with (such as Linux.)
As is typical for an O'Reilly Pocket Guide, the book is pretty terse, and it is not all-inclusive. It does briefly describe each command that it covers, but most entries are between a couple of paragraphs and a couple of pages. It varies depending on the complexity of each command, but most commands include a small bit of descriptive text (typically 1-3 paragraphs), a handful of the most-common options, and some examples. Typical use-cases are covered, but due to space constraints, they really are limited to the most common options; A book this size could probably be taken up solely by covering the options for `ssh`, `grep`, `tar`, and `ls`. (In fact, there is a Definitive Guide for SSH, and a Pocket Reference for `grep`.)
This book is not set up to be a friendly introduction to those who are completely new to the Terminal. However, if you are comfortable with the terminal and could use a handy quick-reference, this is a fine tool to work more efficiently with your Mac.
The book can be purchased here.
-Waldo
Disclosure: I received a free copy of this ebook in exchange for a review.
The "Macintosh Terminal Pocket Guide" by Daniel J. Barrett (published by O'Reilly Media) is a handy quick-reference for leveraging the power of the terminal to use your Mac more efficiently. This book is especially helpful for guiding you through the use of commands that are built-in with your Mac, which may vary from other Unix-like distributions that you may be more familiar with (such as Linux.)
As is typical for an O'Reilly Pocket Guide, the book is pretty terse, and it is not all-inclusive. It does briefly describe each command that it covers, but most entries are between a couple of paragraphs and a couple of pages. It varies depending on the complexity of each command, but most commands include a small bit of descriptive text (typically 1-3 paragraphs), a handful of the most-common options, and some examples. Typical use-cases are covered, but due to space constraints, they really are limited to the most common options; A book this size could probably be taken up solely by covering the options for `ssh`, `grep`, `tar`, and `ls`. (In fact, there is a Definitive Guide for SSH, and a Pocket Reference for `grep`.)
This book is not set up to be a friendly introduction to those who are completely new to the Terminal. However, if you are comfortable with the terminal and could use a handy quick-reference, this is a fine tool to work more efficiently with your Mac.
The book can be purchased here.
-Waldo
No comments:
Post a Comment