Reddit Reddit reviews The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

We found 65 Reddit comments about The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Here are the top ones, ranked by their Reddit score.

Computers & Technology Industry
Industries
Business & Money
Books
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Check price on Amazon

65 Reddit comments about The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win:

u/vaughands · 21 pointsr/cscareerquestions

\> "can't we just install Google Tag Manager" - it's just a block of code in the <head> tag

​

Things your dev will probably be thinking of:

​

What's the performance like for this? Will this block the page load? Is this important? What kind of info is going to collect? Is this complaint with our privacy policy and how we collect info on our users?

​

"Iit's just a block of code in the <head> tag" ... hosted where? From Google? Do we operate in China? Will we ever? Will their CDN work? Can we afford to be reliant on their CDN / resource? Does it work in all the browsers we support?

​

Depending on the scope and reach, this could have a lot of stuff.

​

​

\> "can't we install this countdown pixel on one of our servers? it's just a block of php code" link

​

Do the servers run PHP? Should they? If not, would we need to install it? Who is going to keep that server patched? If it does, where do we put it? What are you using it for, emails?

​

\> "can't we just have read only access to the database? just certain tables? such as a category data, so we can count/sum/group-by categories - what about a staging database - can't we use that?"

​

Maybe a replica. As you've been told, you can't just run random queries since you could hurt performance without proper scheduling and permissions. This takes time. Privacy issues might prevent you from handling it without lawyers involved.

​

Who now has to manage your access? How are the credentials issue? Are you machines secured enough to handle the data or is someone going to click a random link and now get backdoored and now some competitor has access to your info? Oops!

Aside from that...

\> To the marketing team, everything sounds easy "just copy paste this script"

​

Sometimes it is. Often times, it is not. That being said, a lot of stuff can be very simple especially if it's a one off. You should organize time with your teams to get this kind of stuff. Where I work, we do help out with these requests but they are put in queue. However, you have to prove it's really going to help the business. You can't be wasting expensive resources chasing things that not going to return some kind of value for the business.

​

If you REALLY want to understand, reach this cliche book: https://www.amazon.ca/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 Judging by how you are talking, I am sure it will resonate with you.

u/chocolateAltoids · 17 pointsr/cscareerquestions

I wouldn't say it's the exact same, but I still lump it in a nice to read category:

The Phoenix Project

u/MRdefter · 12 pointsr/sysadmin

For me:

Freakonomics <- Showed me a different level of problem solving, via thinking about the motivation behind things.

The Icarus Deception & Linchpin <- Helped me realize I hate doing the work of a cog in a machine and that I enjoy my work if I get to express myself via creativity.

Currently reading:

How To Win Friends And Influence People <- It may be old, but it's still a great resource for human relations, even today. I don't know about most people around here, but I don't like only staring at my monitor 24-7. You can kind of think of it as the start to social engineering. You learn the correct inputs so that you may get the outputs you desire.


Bonus: Not sure if this counts, since it could be considered "technical":

The Phoenix Project <- If you ever interact with non-IT folks, you should read this book. If you are a non-IT person and interact with them, you should read this book. It shows you there are more ways then simply supporting a business that IT should be utilized. I read this after I'd been "doing devops" for a couple years already, and it really solidified a number of points. It's also a great talking point if you ever interview with someone who HAS read it. The only feedback I've received has been positive when I mention this book (to someone who has read it).

edit: words

u/nvanmtb · 10 pointsr/devops

Highly recommend you read this book:

https://www.amazon.ca/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

It details a fictional story around someone in a very similar situation to yours and is kind of a DevOps bible at the same time.

u/gregontrack · 10 pointsr/SQL

I'm very much enjoying The Pheonix Project right now. It gives you a good view of DBA's (as well as other IT professionals) in the context of an entire IT department.

u/fsweetser · 10 pointsr/ITManagers

You might want to read The Phoenix Project. It's an IT fable of a guy getting thrown into a management position in an absolute cluster... mess, and how he clawed his way out via process improvements.

u/healydorf · 8 pointsr/cscareerquestions

Read The Phoenix Project. It's a very good high-level overview of all the things that live under the DevOps umbrella.

Also make sure to acquaint yourself intimately with either Linux or Windows, preferably both, from an ops point of view. Setting up systems, configuring them, deploying/installing things, all that stuff. This stuff is rarely if ever taught in traditional CS programs but is very relevant in the professional world.

For Linux, you can find some RHCSA/RHCE study materials on the high seas which should get you there. The certification is nice to have, but not required everywhere. The knowledge is the important bit.

For Windows, the Microsoft Virtual Academy is a pretty good place to start. Like this one for Powershell basics.

I like this EdX course for covering more of the "dev" side of DevOps with a sprinkle of "ops":

https://www.edx.org/course/devops-for-developers-how-to-get-started

u/malstudious · 8 pointsr/sysadmin

http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

The phoenix project. it was a good book, not so much a reference book, but still has some valuable lessons in it.

u/paradoxops · 7 pointsr/devops

Make sure you checkout What is DevOps? in the welcome section of this subreddit.

If you have some time, get your hands on The Phoenix Project as well. It will give you some perspective.

u/eddit0r · 6 pointsr/devops

The Phoenix Project, explains it in a novel format. https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

u/carbonatedbeverage · 5 pointsr/ITManagers

First, go read The Phoenix Project. A quick read that novelizes process workflow concepts really well.

Personally, I use a Kanban board to make sure projects are moving along. In conjunction with a ticketing system (which is a great log but poor visual representation of how projects or long tasks are going) it works great and is visible enough that my CEO often walks in and takes a look at our "current status." Would be worth looking into as initial investment is low (mine is a whiteboard and some colored post it notes; more elegant and online solutions are plentiful).

u/SuperQue · 5 pointsr/sysadmin

What you want to do is engineer your systems such that "Maintenance Windows" are not a thing. You might want to look into SRE and DevOps techniques.

u/AgileRenoir · 5 pointsr/learnprogramming

I'm going to second that recommendation. DevOps is a really versatile role and you'll want to make sure that you have a solid understanding of the scope involved so that you can confidently set expectations when applying for positions.

It's become a bit of a buzzword in the last year, but for a good reason since it is pretty much essential for agile development and overlaps strongly with architecture / infrastructure development.

There are two books by the same team of authors I strongly recommend reading, including non-referral amazon links below.

  • The Phoenix Project - Explains the approach in a narrative form. If you're only going to get one of these and you're new to the concept, I'd go with this.

  • The DevOps Handbook - More abstract, but a really thorough and well organized examination of both DevOps as a discipline and the road to implementing it in an organization.
u/engagThe · 5 pointsr/sysadmin

Obligatory referral for reading the Phoenix Project.

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

u/Byzii · 4 pointsr/sysadmin

Change control issues automatically make me think of Phoenix Project.

A great read for anybody in IT.

u/YuleTideCamel · 4 pointsr/learnprogramming

I'm a technical PM for two teams, as a well a contributing dev on both teams.

While the skills are definitely different from programming a few things I've found that helps:

  • Get to know AGILE really well. Read the manifesto, read about scrum vs kanban . Understand each's strengths and how to do the process correctly for both. I tend to think SCRUM is like fitness, you have to do it right to get the full benefits. If I go the gym and work out then, eat a gallon of ice cream everday, I won't be fit.

  • Understand how to write good user stories, look into different patterns people use . For example the "As a <user> " format is quite popular but really understand how to flush out stories .

  • Avoid strict timelines (I know you mentioned it in the OP) but a PM can't be 100% rigid on timelines and even suggest them . The way that works for our entire company is we base everyone complexity and use the fibonnaci scale to estimate complexity by having multiple people on a team vote. I (as the PM) look at past velocity (how many points we completed) and then project out how long something will take based on the point values estimated by the team. This works FAR better than "oh it will take 2-3 weeks". People are bad at time estimates, complexity estimates are a much better gauge.

  • Practice your networking skills and diplomacy skills. Part of being a good PM is having established relationships with other teams and getting things for your team. A good product owner is a leader, but not a dictator. You don't tell the team what to do, you set the vision, and remove any blockers in their way. As part of this too is being available to answer questions.

    A few books you should read:

  • Notes to a Software Team Leaders Even though its focused on being a lead/supervisor, you can get a lot of good insight on how to help guide the vision of a team.
  • [Scrum: The Art of Doing Twice the Work in Half the Time] (https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X). Really good book on understanding the spirit behind scrum, with real world examples. Not very technical , more about why rather than what scrum is. I've read this several times.
  • The Phoenix Project. Good book about breaking down barriers between teams and working towards a shared goal. It is devops focused, but I believe product managers would benefit from reading this as it illustrates the importance of shared ownership, automation and avoiding silos.
  • How to Win Friends and Influence People. Great book on interpersonal relationships and how work with others.
  • The Clean Coder. A book focused on professionalism for developers (not so much the code, but overall environment/culture). This is a good resource to understand the dev cycle in the real world and what teams should be doing to be professional. This will help you when making decisions on specific things to focus on.

    In terms of sprint plannings, just remember it's a negotiation. You're not there to tell people what to do. Rather you have the stuff you would like done, but you negotiate with the team on what's possible and what's not. I've seen too many PM's get pissed cause their teams couldn't do 100% of what they wanted and that's not right. Rather a good PM, imo, brings options and lets the team decide how much they can handle. There have been times when I've gone into sprint plannings and non of items made it on the sprint, and that's ok.

    Sorry for the long rant!
u/VA_Network_Nerd · 3 pointsr/gmu

Come prowl around in /r/ITCareerQuestions a bit. See what everyone is talking about.

There are lots of ways to build a successful career within IT.

I've been doing this for almost 25 years now.
Based on what I am seeing around me, in my opinion Linux Systems Engineering is the hot ticket.

A solid Linux foundation makes you ready to work in Information Security, Cloud Architectures, Data Center Tech, Automation and all kinds of other shit that has dollar signs all over it.

Take a damned class in Python and take that shit seriously.
Python as an automation tool is powerful stuff with all kinds of applications within any business environment.

Take a damned class in Information Security. Whatever you wind up doing within IT, you need to do it with an eye on security requirements and implications. Take that shit seriously.

GMU has a fairly well organized Competitive Cyber Security club.
Go check them out. If that doesn't quite feel like your area of interest, that's cool.

On your very first day on campus, after the insanity of move-in day, you go find Career Services on campus.
Be polite. These are the people that are going to help you get a job later.
Ask them when the next technology career fair is on campus, and you plug that shit into your Google Calendar.
Get your happy ass to each and every single career fair and you learn how those things work. Talk to some recruiters. And you see if you can get yourself a summer internship - EVERY YEAR. Don't be too surprised if you strike out Freshman year. Not many employers want to hire Freshmen. But you go anyway and learn from the experience of interviewing and being interviewed.


Go to the library at your High School. Look for or ask for this book:

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

I encourage you to get it from the library because it isn't a reference book that you will read over and over. It's more of a read once, expand your mind, and move on with life with an enhanced perspective kind of book.

It isn't terribly technical. Anybody with the slightest interest in IT should understand it.

Good luck.

u/exotic_anakin · 3 pointsr/learnprogramming

One idea is reading more about soft-skills and process stuff, rather than nitty-gritty tech stuff. Books on Agile for example are great. I also listen to a lot of podcasts in that kinda scenario.

Some books that might be good for you:
- https://www.amazon.com/Clean-Agile-Basics-Robert-Martin/dp/0135781868
- https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition
- https://www.amazon.com/Soft-Skills-software-developers-manual/dp/1617292397
- https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

u/huck_cussler · 3 pointsr/learnprogramming

I'm a software engineer and not in DevOps. However, one of the managers at the company where I work encourages all the developers to read The Phoenix Project, and if/when they finish that she gives them a copy of The DevOps Handbook.

I'm about halfway through the former and haven't started the latter. The Phoenix Project is a novel, but it's kind of like one of those novels with a message, in this case the message is how to be part of a successful IT department at a modern company.

u/EnergyCritic · 3 pointsr/devops

/u/HostisHumaniGeneris has a pretty exceptional definition.

The only thing I'd add is my own personal experience. DevOps is a philosophy -- not a team name or a position. For example, a developer can be a "DevOps developer" or a company can be a "DevOps company" as if it's a quality of their performance, but not a purpose. Your actual role shouldn't really include the word "DevOps" because at the end of the day you're still doing IT, or Operations, or Systems, or Development.

The reason being is that for DevOps philosophy to be implemented, all levels of the team need to be on board with the philosophy.

Read "the Phoenix Project" -- for example -- to get some ideas about what DevOps is really about.

u/Ashex · 3 pointsr/devops

You guys need to change how Dev works with you, I'll elaborate once I'm at a computer.

Edit:And I'm back

Where are these apps coming from? What's the driving need for them? Do they serve a business purpose? If so, do they drive revenue or productivity? You guys need to have a chat with the development managers or Director to figure out what their roadmap is for all these apps. They have an idea of their purpose but they're not involving Ops which is a major deficiency when we're looking at adopting a DevOps culture.

When looking at Ops being the constraint, what particular aspect is the constraint? A specific person or process? Isolate the constraint then protect it, if it's a person you're pulling off projects you need to figure out why they're getting pulled off them and remedy that.

As for a technology to look at for a solution, start using Docker. Create standard Docker templates and provide Dev with those as their platform, if they're creating apps for production then you need to provide the standards they deploy to/develop for.

Now go read The Phoenix Project, I'm deadly serious about reading that book as you have a major communication breakdown that is resulting in an insane amount of projects being thrown your way.

u/ski-dad · 3 pointsr/sysadmin

Sr. Director checking in - required reading IMHO:

Turn the ship around

and

Phoenix Project

u/lobops · 3 pointsr/brasil

Na verdade, cria-se muito mito em cima de nomenclaturas. O SRE veio da engenharia de software como bem aborda aquele famoso livro do Gene Kin o The Phoenix Project: A Novel about IT, DevOps... . O SRE hoje pela definição de onde se originou (o Google), e atuando dentro do Google propriamente, é o que seria em tese o nome que se dá erroneamente ao (Engenheiro DevOps)...que sabemos ser um nome de mercado...uma vez que na teoria não faz sentido algum.

​

O SRE é o cara que compreende a arquitetura dos projetos, de lógica de programação (podendo atuar nas mais diversas linguagens), apesar de ter maioria em python e GO, mas que resolve todo tipo de problema relacionado principalmente a operações. É uma tentativa de mercado de resgatar o MacGyver , que consegue juntar um chiclete e um clips e produzir uma bomba, mas com a intenção de contratar um Chuck Norris . No fim das contas, na prática, é o profissional pau para toda obra. O foda é quando pagam mal por isto.

​

Outra coisa também que atrapalha é o EGO e VAIDADE das pessoas em se entitularem tais coisas. Mal sabem da cilada que podem estar se envolvendo. A cilada de enganar o empregador que tem espectativa maior do que aquela que você anuncia, ou a cilada de cair uma porção grande de problemas no seu colo que muitas vezes não há maturidade e experiência para resolve-los. Essas coisas eu vejo com certa frequencia e claro, sempre me disponho a ajudar. Mas é bom dar este toque.

​

​

u/plasticphyte · 3 pointsr/sysadmin

>Fast forward 4 months to the present, and I have had barely any time to work on any aspect of this certification during normal working hours (I mean within the 40 hours per week that is the traditional work limit for employees). I have had a little time to work on the certification in the office, but at least half of my work for this has occurred outside of the 40 hours.

Sounds like your problem isn't ISO certification, but an issue with workload management.

>Since this is a sysadmin job, I have also had to work outside of the 40 hours on other critical tasks (fixing crashed servers, patching servers, installing network devices, etc).

Sounds like your problem is really this. Do you have any sort of patch management systems in place? Do you have automation setup with stuff like puppet, chef, or salt, etc?
Do you have staff in your team that are wasting time, or could take work off you?
Are you just applying bandaid solutions where you really need to fix the underlying issue with faults, etc? What about preventative maintenance, etc.

If you haven't, I suggest reading The Phoenix Project; it is a fantastic read on how a fictional troubled IT department is required to meet a hard deadline, and the process they went through.

Available as an eBook or printed copy here: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

I am, of course, saying this without knowing what your work environment is like, or what staffing levels are like, etc, but without doubt, the very first thing I think of when I see people talk about, or tell me that they've got issues keeping up with their workload, is that it's usually because they haven't taken a good look at what they really, genuinely need to do to get business outcomes.

Put another way, do you really need to put a TPS coversheet on every report?

u/jmreicha · 3 pointsr/networking
u/somahaiken · 3 pointsr/sysadmin

I highly recommend starting with The Phoenix Project. Don't pass by this book just because it says "DevOps" in the title. It quite specifically addresses the ideas of change management, why they are important for IT, and more importantly why they are important for the business.

Then once you're sure you're ready for Change Management, The Visible Ops Handbook is a more prescriptive book that will help you on the beginning stages of implementing Change Management.

u/msphugh · 3 pointsr/sysadmin

The Phoenix Project sets its main villain as the manager of the security department who can't see the forest for the trees.

Spoiler alert: He shaves his head, achieves enlightenment and all is saved.

u/TheTiwaz · 3 pointsr/devops
u/elnsoxo · 2 pointsr/sysadmin

Your situation is remarkably similar to The Phoenix Project (http://www.amazon.com/gp/aw/d/0988262592). I encourage you to check it out.

It sounds like your company doesn't believe its success is dependent upon a well-managed IT infrastructure. Which business goals are jeopardized by this behavior? How can you effectively communicate that 1) without properly planning capacity the IT team might as well be a gulag, and 2) without controlling what work is released to IT, it is destined to be perceived as a cost center instead of contributing to the company's value stream?

...have you ever been able to say no to a business/development proposal that got dumped on your team?

At the very least, the book might provide some consolation that your IT pains are not unique :]

u/rubsomebacononitnow · 2 pointsr/jobs

HIM is the core of all badness in healthcare. I assume you know this but the fact that it's a total disaster in general is responsible for my income. Have you read the Phoenix project?. To me that's a must read for anyone in IT management. It literally changed how I saw things. You can read it in a day. Trello for Kanban, with slack integration can be amazing.

When I interview I talk about the 4 types of work and how they handle flow. I'm a consultant so I need to understand what sort of a disaster I'm getting into. You need that info to especially since you're early in the year and course is somewhat laid in.

For interview questions I'd be prepared to answer MU, HIPAA (Cfr 164), HITECH (13410d). Budgeting, team management and find out if you gel with the CIO. Most of them aren't morons but some are simply incompetent.

I wish you the best!

u/l11uke · 2 pointsr/sysadmin
u/massivechicken · 2 pointsr/security

The Phoenix Project (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592)

Whilst it's not primarily about security, it does play a major role in the story.

It's important as a security professional to see where the industry is headed, and how security can adapt.

I found it a great read from a security perspective.

u/metamet · 2 pointsr/devops

Here's your homework:

u/bartturner · 2 pointsr/Stadia

Software engineering is different than many other things. It takes a lot more than just wanting. It also can't be accomplished with just money.

I can't tell you how big of a role that leadership and vision play in the equation.

But it is then the process. That is where Google has really been a leader. Google basically invented the entire SRE/DevOps space.

Wrote the canonical book on the subject. Well the latest one.

To me it is The Goal and then Phoenix Project and then you finish with the Google SRE book.

You read in that order. If a software engineer it will change your perspective if not yet read. Google just read them a lot earlier than others.

Here is a link to the books I am talking about if do not work in the field

https://en.wikipedia.org/wiki/The_Goal_(novel)

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

https://landing.google.com/sre/sre-book/chapters/introduction/

u/spaghetti_boo · 2 pointsr/devops

DevOps is broad - very board. Some say it's not even a "thing".

Your request is quite broad.

I'll do my best, and feel free to ping back any specific questions as all DevOps requirements are conditional based on your working context.

Considering your background, and your current approach to DevOps, I'd suggest reading up on DevOps culture, generic tooling (in various classes), amongst various other topics (apologies for the ambiguity here, but there is too much without more specific context).

DevOps Tooling Classes:

  • Source control: Strive for all your day-to-day activities to be represented as code in some form.
  • Automation using CI pipelines (Git, Jenkins/Teamcity, etc).
  • Automation from a configuration management perspective (Ansible, Chef).

    (Naming a minuscule fraction of the available tooling.)

    Ask yourself these questions to help you with your Google'ing:

  • What is a CI pipeline?
  • Can I read JSON and YAML?
  • What is Kanban?

    If I had to sum it all up, and give you the best vectors to approach this:

    Think of DevOps as being able to deliver a business requirement using reliable and reproducible techniques:

  • "Everything-as-code."
  • "Community effort."
  • "Monitoring"
  • "Simple is key."

    As I mentioned before, DevOps is very broad.

    Read https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

    Ping back for help! That's what DevOps is all about!
u/erotomania44 · 2 pointsr/AZURE

As an Enterprise Architect, i believe you would need to have a great understanding of the nature of your business.. Around asset depreciation (in effect does it make sense for you to close down your datacenter?), how outsourcing contracts affect your P&L etc. Also around what the outlook of the business is - is your business looking at net new business models or possible adjacent markets? If no, then a cloud migration/transformation probably doesn't make alot of sense (also, if the answer to that question is no - do you think your organisation will survive in the next 5 years?).

Reason being is a cloud migration/transformation will never be cheaper than running things on-prem/outsourced, not unless your workload was purpose-built for the cloud - from an architectural PoV, this is what the industry calls "cloud-native".

Now, if you're still with me - then that means that you have good reasons for moving to the cloud. I would advise to start small - never, ever do a big-bang. Approach this like you would a scientific experiment. Form a hypothesis, have a controlled group and variable group, then evaluate, learn, and adopt. If you're wrong, pivot, then try something else. If you're right, build on top of that then scale.

You will probably realise that doing things this way sound alot like Agile - and they are similar. You might also feel that existing tooling and your organisational structure doesn't allow for that kind of work - as you will optimize for speed and getting quick feedback from your stakeholders (or customers). This is the fundamental problem of cloud adoption within enterprises - enabling a large organisation to work in this way, while making sure that you're not breaking any laws or regulation. Organisations who fail at this simply move their costs to the public cloud provider, then complain that it's too expensive without achieving real value, then decide to move back on prem (costing millions again).

This will require : a) Organisational change - grouping people not by function, but by the value they deliver towards a company goal or outcome and b) Cultural change - a culture that embraces change, and the failure that comes with it. And not resting on your laurels once you achieve success; and lastly, c) Architectural changes - towards decoupling, independence, and resilience.

There's alot of content out there (including the ones you mentioned) that will help out for C - Architectural changes, but not much for the first two.. It is, arguably the easiest part of the three, unfortunately.

Oh, and one more thing - there's this thing called DevOps as well - not the tools surrounding it, but rather the discipline and culture that comes along with it. I'd recommend you to read https://www.amazon.com.au/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 before anything else.

​

​

​

u/ferstandic · 2 pointsr/ADHD

I'm a software developer with about 5 years of experience , and I used to have the same sorts of problems where I would over-commit to getting work done and under-deliver. To summarize, I changed to where I only commit to tasks that will take 1-2 days or less at a time, and I make it very very public what I'm working on in order to manage both my and my team's expectations. Here are the gritty details (ymmv of course):


  1. I got my team to start using a ticketing system and explicitly define what we are working on with explicit acceptance criteria for each ticket. That way you know where your finish line is. There other huge benefits to this but its outside of the scope of your personal workflow. This of course takes buy-in from your team, but at the very least start a board on trello with "todo", "in progress", and "done" columns, and try to keep the number of items "in progress" to a minimum, and work on them until their finish. A cardinal sin here is to move something from "in progress" back to "todo". This thing you're setting up is called a kanban board

  2. I break the work I do into 1 or 2 workday 'chunks' on our team board, so I don't lose interest or chase another issue before the work I'm doing gets finished. Keep in mind that some workdays, depending on how heinous your meeting schedule is, a workday may only be 4 (or less :[ ) hours long. An added bonus to this is that its easier to express to your team what you're working on, and after practice chunking up your work, you and they will reasonably be able to expect you to finish 2-3 tasks a week. There are always snags because writing software is hard, but in general smaller tasks will have a smaller amount of variability.

  3. As I'm coding, I practice test-driven development, which has the benefit of chunking up the work into 30 or so minute increments. While I'm making tickets for the work I do, i explicitly define the acceptance criteria on the ticket in the form of tests I'm going to write as I'm coding ( the bdd given-when-then form is useful for this ) , so the flow goes write tests on ticket -> implement (failing) test -> implement code to make test pass -> refactor code (if necessary)

  4. This is a little extreme but I've adopted a practice called 'the pomodoro technique' to keep me focused on performing 30-minute tasks. Basically you set a timer for 30 minutes, work that long, when the time elapses take a 5 minute break. After 5 or so 30-minute intervals, you take a 20-30 minute break. There's more to it, but you can read more here. Again, this is a little extreme and most people don't do things like this. Here is the timer I use at work when its not appropriate to use an actual kitchen timer (the kitchen timer is way more fun though). There's a build for mac and windows, but its open source if you want to build it for something else.


    Side note: in general I limit my work in progress (WIP limit) to one large task and one small task. If there are production issues or something I break my WIP limit by 1 and take on a third task (it has to be an emergency like the site is down and we are losing money), and I make sure that whatever caused the WIP limit to break gets sufficient attention so that it doesn't happen again (usually in the form of a blameless postmortem ) . If someone asks me to work on something that will break the WIP limit by more than one, then I lead them to negotiate with the person who asked me to break it in the first place, because there is not way one person can work on two emergencies at the same time.

    Here's some books I've read that lead me to work like this

u/20_more_1_mores · 2 pointsr/security

Doesn't matter the year, The Phoenix Project is a must.

u/caligolae · 2 pointsr/devops

By its very nature, DevOps roles are typically not "junior", and you'll have to have earned your mid-level stripes in systems/operations/cloud engineering to graduate on into DevOps.

Read [0] "The Phoenix Project" and [1] "Leading the Transformation" for an introduction to what DevOps theory/philosophy is all about. It's really worth taking the time to study these books, even if what is in them may not be something you're going to apply at your current job.

Get an [2] AWS certification. As a difficult and rare exam, companies looking view those who hold the DevOps Engineer certification in high esteem.

[0] http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

[1] http://www.amazon.com/Leading-Transformation-Applying-DevOps-Principles/dp/1942788010

[2] https://cloudacademy.com/learning-paths/devops-engineer-professional-certification-AWS-13/

u/luser1024 · 2 pointsr/sysadmin

I agree with you, in a way.

In my experience an entire IT team may be 50-60% effective but it's because of a single person doing 100% their own capacity. There seem to be alot of people who slack off while their colleagues pick up the slack. This isn't always laziness. It could be that they don't have the proper skill sets, may have apprehension in working with some technologies, or aren't familiar with the entire environment enough to do things themselves. This is sort of like the scenario presented in the phoenix project

Work doesn't get done because of the single person working at capacity and other people "blocked" on that person. This gives the illusion of a very busy IT team and lack of staff but in reality management just needs to address the underlying issues... again, kind of like in "the phoenix project" :)

u/pspenguin · 2 pointsr/brasil

realmente, não há exatamente um consenso sobre o que é devops, mas a meu ver é mais um filosofia do que realmente uma função. é um modelo de trabalho que procura quebrar os silos funcionais dentro de uma empresa e trazer uma maior integração entre elas, trazendo maior agilidade e resultados mais rápidos. Tudo isso permeado com bastante automação e melhoria continua sempre focado nos beneficos que isso vai trazer pro negocio. Sei que falando desse jeito parece um conceito bem vago, mas é algo que envolve coisas como:

  • automatizar infra-estrutura, para que o provisionamento seja mais eficiente, padronizado e reproduzivel
  • ambiente de entrega continua (continous delivery) - onde as aplicações vão "pro ar" de maneira automatiza e continua, e isso inclui uma serie de etapas como automatização de builds, testes e deploy
  • monitoramento e aprimoramento dos processos de recuperação, basicamente fazendo com que os problemas sejam corrigidos de maneira automatica, aumentando a resiliencia do ambiente.

    Esse link aqui pode te dar uma boa introdução no assunto: https://theagileadmin.com/what-is-devops/

    Além disso, te recomendo fortemente que leia um livro chamado The Phoenix Project, que conta a historia de uma empresa fabricante de auto-peças que precisava ganhar agilidade para enfrentar a concorrencia ou estariam fadados a fechar as portas.

    https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592
u/telecomando2 · 1 pointr/sysadmin

Also, for some reason I keep thinking "Maybe Reading the Phoenix Project might help." It was free on amazon a few months ago so I read it (thanks to the people here for the suggestion) and it was interesting. There are tons of eye roll moments and it can be silly at times but it does help your thinking when it comes to being buried in neck deep in projects. It's probably worth the $10 to read it as a piece of fiction alone.

http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592/ref=sr_1_1?s=books&ie=UTF8&qid=1369923896&sr=1-1&keywords=the+phoenix+project

u/mobileagent · 1 pointr/computertechs

I dunno...sounds nice in theory, but it's going to make you more of a cost-center than they already think you are. Half of your job is going to be demonstrating that you ADD value to the organization, not just be a big money pit. And that's without tying up development resources on things that look a lot like a big money pit in the eyes of upper management. I don't know what your timeline is, but is it long enough for development?

Come to think of it, maybe read this...it's almost like Zen and the Art Of Motorcycle Maintenance but for IT management, or a big long parable (That is, it's a relatively short book, but long as parables tend to go...or is it an allegory...meh). I don't know, I thought it was interesting, and I'm just a tech (that said, only picked it up because it was during a free promo.)

u/Chipotle_Turds · 1 pointr/ITCareerQuestions

Learn the fundamentals of devops and how it relates to your company's technology usage and process.

Read the Phoenix Project, it will give you a better insight on how devops fits in with IT in general.

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

For technical skills it wouldn't hurt to know improve your scripting/programming skills.

u/bostonou · 1 pointr/bourbon

Haha guess I saw the "tipsy" and checked out after that! My focus is functional programming, so most of my recommendations are around that.

LambdaCast and The REPL are good and worth listening through (full disclosure I was on the REPL).

Other casts that I cherry-pick through:

u/facetrolled · 1 pointr/cscareerquestions

DevOps is a tough field to break in to. A lot of companies will expect you to come in and know what you're doing right away - especially from a security standpoint. Managing infrastructure for your organization is a really big deal, which is why there is so much emphasis on Linux administration and deep understanding of how to secure those resources.

Going from web development to devops is a pretty big change - really they are two separate career paths. Not that you couldn't do it, but it will be a difficult transition for someone that hasn't done that kind of work before.

I think you need to assess what it is in the technology sector that interests you before you make a decision on which path to go down. Doing Devops-style work is super fun and rewarding, but like I said - it is a completely different field than traditional SWE.

If you do look in to the devops path, I would highly suggest reading Google's SRE book (it's free on PDF -https://landing.google.com/sre/sre-book/toc/index.html). This will give you a really comprehensive breakdown on what aspects of the SRE/DevOps that you will want to focus on to be successful.



e: also - the Phoenix Project (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592). A must read for any DevOps hopefuls out there.

u/bluefirecorp · 1 pointr/sysadmin
u/MiataCory · 1 pointr/sysadmin

Do what your boss is telling you to do.

Let. it. break.

If the halls runneth over with trouble tickets, just do your 40 hours and go the fuck home.

Patching it along is making the case that "This doesn't need fixing, because it still works."

Go read "The Phoenix Project", and quit being a Brent. You're doing things wrong, and your company is hurting because of it.

u/Jenjafur · 1 pointr/sysadmin
u/lerun · 1 pointr/sysadmin

DevOps is a pretty large field and it is not only tech.
For beginners I would recommend reading the Phoenix Project, it's a novel about a bunch of ppl and you follow along as they make the journey from traditional IT to the DevOps way. It's a nice introduction, though it does not give you answers for how to do DevOps (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592).


DevOps is the next step in making Development and Operations work better together with less friction. To achieve this one needs more lean processes and better tooling.
The tooling part is where you would put automation that help lessen the burden of everyone.
DevOps is a bit in the hype, and many understand it as a magical bullet that will make everything so much easier. Though this is not true, it takes a lot of effort to develop and maintain automation.


I'm working mostly with VSTS (Visual Studio Team Services) and Azure. Here I develop Powershell code to make it easier for code to flow through our different environments by leveraging tech to help remove some of the more burdensome processes.

Though if Operations does not already have a good ITSM framework in place, and you have Developers that just want do whatever the hell they fancy. The road to DevOps will be a hard one.

I did not have much DevOps experience when I started, though I had a strong background from Ops where I was well versed in how to merge processes and tech beforehand. So it was just an extension of this. Also my Powershell skills are good enough so I can write the automation I discover is needed as I investigate the existing glue in place between Dev and Ops.

I would say the biggest hindrance for most to do great DevOps is control of WIP (Work in Progress). This is Business Projects, Internal Projects, Operational Change and Unplanned Work. If one can visualize all these types of WIP flowing through Dev and Ops, one have a good foundation to build the rest on top of.

u/ntrabue · 1 pointr/sysadmin

The Pheonix Project is a wonderful read and even has a gripping story. I think it was my first audible book.

u/brazzledazzle · 1 pointr/sysadmin

You can try channeling that passion into trying to save the organization. Can you utilize or build tools that make managing things easier? I would imagine you are, but if you're not, have you looked at configuration management stuff like puppet, chef ansible or saltstack? Orchestration tools like mcollective, fabric or capistrano?

It sounds like you have a lot of issues with the dev side of things and the whole silo thing is a pretty well understood problem at this point. Can you introduce devops concepts? This book might be a good place to start:
The Pheonix Project

If you're going to go down the savior path, one key thing that you have to remember is that you might fail and they'll continue down the path until they have no choice but to deal with it or go under. And I would say that failure is quite likely too, you're going to be viewed as someone that makes waves. If you don't demonstrate the value of the change and/or don't hold a lot of political capital, you're going to be fighting uphill.

u/myhomebasenl · 1 pointr/scrum

Ok, you can start with some reading in books.

A suggestion: Scrum a Pocket guide - Gunther Verheyen

If you like a good novel (about DevOps): https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

​

If you going for training, go for PSM 1 first (prefer that your boss is paying :)). This will give you a lot of background theory on Scrum, specially if you participate in a class. If being Product Owner is more suiting late, you have the advantage of having the theoretical background already.

​

Good luck in your journey! :)

Cheers, Johan

u/elacheche · 1 pointr/sysadmin

That's a great book! I also recommend this book /u/sudz3 → The Phoenix Project

u/mfukar · -2 pointsr/programming

They're the same. It's manufacturing. It doesn't matter what each one builds.

Not that this justifies interruptions. Interruptions are bad in both cases.

I would suggest you as well as anyone reading this, especially those who are about to downvote it, to read this book. It is the most accessible and intuitive example of why software engineering is not an art as it is often referred to and thought of, but a very familiar assembly line.