I would be very cautious before you start this. You need to have a much better understanding of why you’re doing this before you start. I think breaking up ops teams may be an answer to a different question. That question should be: “how do I deliver better business value?”

The first step is to understand what you’re trying to achieve. Gene Kim, Patric Debois et al talk about the “three ways”. It’s essentially three steps towards embracing devops culture.

The first is all about increasing flow through the system - that system being your organisation. The idea is to look at how your organisation goes from a business need to realising business value. For instance, how do we go from wanting to provide another payment option on a website, to customers being able to use it?

One way of analysing and visualising your organisation as system is something called “value stream mapping”. This looks at how a piece of work gets requirements, gets developed and how it gets to customers (even if that’s internal customers). You need to understand the process, where the delays are, where teams hand off from one to another, where things go wrong. Ideally you want to optimise this process. One of the issues that many organisations look at just automation and essentially automate a slow and inherently crap process. This will never give the returns that many people are after. Looking at this level, you should be looking at organisation goals. How do you measure this work in a frame that other people are going to understand who are not IT? Is it how fast you can get a feature to market? Increasing individual spend? Increasing reliability of the service you provide to customers? If you’re not framing this initiative in those terms, then it’s doomed to failure. Be specific and measurable.

Once you understand your process, you can look at opportunities to optimise the feedback loops (the second way). It might be that infrastructure is required by dev teams that gets delivered by ops but isn’t what they need. There is a team hand-off here that needs to be addressed. There are many solutions to this problem, but it might be a start to move where the person provisioning that infrastructure sits. Put them in the dev team. You might still keep them as part of the ops team logically to start out with. The point is, you’re looking at the system, understanding the constraints and trying to optimise pain points.

You can achieve a lot without adding any new automation or technology solutions and this shouldn’t be underestimated, but ultimately, handcrafting systems isn’t repeatable or fast enough. This is where reorganising teams might look sensible, but you should know what outcomes you are string to achieve. That might be difficulties provisioning infrastructure fast or flexibly enough, it might be deployment of code to live being too slow, it might be that testing is too slow. Once you know you need improve, you can look at tooling to better achieve that.

/u/quailtop mentions:

>In my (admittedly limited) experience, you can solve needing faster development velocity (the first problem) through staffing a new team whose job it is to help improve the deploy, test and release process for all developer teams. Their job is necessarily cross-cutting across all dev teams. They would develop internal tooling e.g. a standardised build/release process that all teams can employ. This is a great pattern because it avoids encroaching on existing territory and is a very clear contract between engineering.

This is otherwise known as the DevOps “hub and spoke model” and is what my organisation has implemented. It’s worked very well for us and it’s a clever way to start a reorg.

For certain ops teams, you may want to keep them together. For example, you may have a large and complicated network setup and still need a dedicated networks team. My focus then, would be putting an obligation on those teams to allow others to better consume their services. They may need to add other people to this team to make that happen. For example, if you have a complicated network, with lots of steps, look at both automation of those steps but also to allow other teams to more effectively consume them. Amazon spent a lot of effort building the culture that ever system or service is an API that should be able to be consumed easily internally (have a read here: https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ . So, for this case, you may add a tech lead and some software engineers to build network APIs rather than splitting the team up. This may include some of your more traditional network admins to look at replacing on prem infrastructure to support this. The goal however, should always be about the organisation level goal. Improving the speed at which you can reliably deploy network changes should be in support of one of those strategic objectives.

The third way then focuses more on continual learning and experimentation. You should have embedded a set of objectives that you’re working on achieving but you’ll have lots of legacy systems, legacy processes and behaviours. Focusing on outcomes and consistent asking of “why?” will start to help. This is also where SRE becomes really relevant for me. IMO SRE isn’t something that is particularly useful to start out with. It’s best when you’re looking at elevating and existing DevOps culture to a new level. This will look more at observability of a systems and understanding where the more difficult optimisations can be done.

Let me be clear. DevOps is a long road for any organisation to change to. To really get mature it will take many, many years to properly bed in. My organisation started around 5 years ago and we still have more progress to make. One of which is to move from project based way of organising work to more long lived product teams. This organisational change is probably the biggest thing holding us back right now, and has nothing to do with automation or technical practices.

I wouldn’t start out by reading about SRE, I would start with a book called The Phoenix Project and then read The DevOps Handbook, at least twice. Start with the strategy before you make any changes. I would also look to see if you have a cloud strategy because many of these practices are much harder to implement purely on premise.

​

Edit: Thanks for the silver!

Edit2: One thing that's also worth noting is that for many people, moving from traditional sysadmin to DevOps is a hugely scary change. It means that many of the staff won't have the job security they thought they had and they need crucial skills they don't have. To make this work, understand this point of view and support them. This requires really mature and experienced leadership at all levels. This is a good, short and free ebook to help the more traditional sysadmins understand why they have to change.

(1) Read, bruh. I can't vouch for it personally, but I've heard the book Watching Baseball Smarter recommended with high regard. And it's almost literally the exact thing you asked for. Here are some other good book recommendations:

• Moneyball by Michael Lewis. Hard to believe that the book is sort of old hat at this point, but it still serves as a very readable introduction to advanced statistics.
  
  
• The New Bill James Historical Baseball Abstract by Bill James (mostly). This book is good toilet reading, if you have a massive toilet on which to perch it, and your bowel movements are glacially paced. James ranks the best players at each position, and goes on a witty, decade-by-decade jog through the history of the game.
  
  
• The Book: Playing the Percentages in Baseball by Tom Tango. Are you a "math person"? Read this book, you'll like it. It's an introduction to sabermetrics that explains the important first principles of statistical analysis, builds an important statistic (wOBA) from the ground up, and then applies all of that knowledge to answer specific questions about baseball strategies and to debunk, verify, or qualify some of baseball's hoary "conventional wisdom."
  
  
• The Amazing Adventures of Kavalier and Clay by Michael Chabon. This book is not about baseball, but it's still great and you should read it.
  
  (2) You'll want to start watching the game more, if you can. Find a method (like MLB.tv or, you know, your television) to do so. Massive exposure does help you learn, and it's a fun, if inefficient, method. Osmosis. That's just science.
  
  (2b) Depending on the broadcast crew, it's sometimes addition-by-subtraction to mute the television.
  
  (2c) If you have MLB.tv Premium and intend to follow your favorite team, I recommend watching the other team's broadcast. You know enough about [TEAM X] already. Learn something new about [TEAM Y], instead. Unless, of course, (2b) applies, in which case maybe your best bet is MLB.tv's option to overlay the radio broadcast on the TV video. Barring that, the liberal application of the DOWN VOLUME button is always an option, and then, like, listen to Chopin's Preludes. Don't be That Guy and lean too heavily on No. 15, though. There are 23 others. Expand your horizons.
  
  (3) When you go to games, keep score. Sure, there's a guy a few seats over in a striped button-down and pre-faded jeans (Chad or something) who will mock you mercilessly for it. Sad for you, you've lost Chad's respect. But, oh, the things you'll gain. A free souvenir. A better grasp on the flow of the game. The priceless power to answer the "what did I miss" and "what the fuck just happened" questions that litter the air at ballgames, tragically disregarded and forgotten like the syllabi from Chad's last semester at Bromaha State. You can learn how to score ballgames here. Fuck Chad.
  
  (3b) Go to games alone now and then. Did I mention that, in some company, it's rightly considered rude to score a ballgame like a trainspotting anorak? Not in all company, mind you. But I like going to some games alone to avoid the messy politics of divided attention altogether.
  
  (4) Bookmark a few websites. Quick stat references include FanGraphs, Baseball-Reference, and Brooks Baseball. Grantland, Baseball Prospectus, Baseball America, and the Hardball Times are all good. FanGraphs and Baseball-Reference both have subscription options that allow you to access enhanced content for a small fee, which is worth it if only to support the yeoman's work that they do compiling and sorting our beloved numbers.
  
  (5) German chess great Emanuel Lasker is believed (incorrectly) to have said that "if you see a good move, look for a better one." Good advice. Too much of the history of baseball analysis is the history of people getting stuck in comfortable places and refusing to interrogate their own ideas about the game. Sabermetricians have made careers out of just pointing this out, and even some of them do it from time to time. Also, on the level of pure self-interest, baseball ignorance and bad teeth have this much in common: Keeping your mouth shut hides them both. If you have a good opinion about a baseball topic, look for a better one.
  
  (6) Watch a some decent movies about baseball. Sugar is excellent and disturbing. Baseball: A Film by Ken Burns is available on Netflix and worth watching. You drink his nostalgic Flavor-Aid at your own peril: At times, Baseball is about as edifying as having a good, 19-hour stare at a Norman Rockwell painting. It's still in a class all its own as a baseball documentary. You should also watch Ed, starring Matt LeBlanc, because it'll teach you not to take strangers on the internet seriously when they give you advice.
  
  (7) When you go to games, wear whatever the hell you want. This has nothing to do with understanding baseball, but it annoys me when people make a big deal out of policing the clothing that others wear to sporting events. Sitting front-row at a Yankees-Tigers game in your best Steelers jersey and a pink Houston Astros BP cap? Whatever. You be you. You be you. I once watched as a perfectly innocent college student was denied a free t-shirt from a Nats Park employee because he (the student) was wearing a Red Sox shirt with his Washington cap. That was pretty fucked.
  
  (8) Take the EdX Sabermetrics course. Others have recommended this, with good reason. It's a wonderful introduction to advanced analytics, and you get a taste of programming in R and MySQL as well. You don't need a CompSci background. I sure didn't.
  
  Hope this helped.
  
  Footnote: Chad-hating is actually too easy. Truth is, I've never really been mocked for scoring games. Once, I even bonded with a Chad-esque guy sitting next to me at a Braves-Nats game here in Washington. He was pretty drunk, but we talked Braves baseball while he drank and I drank and I scored the game and he drank more. He seemed utterly engaged by the scoring process in that guileless, doe-eyed way that only the drunk have mastered. That's the Chad I loved.

From across the pond, welcome to pretty much the best sport ever! We're glad you're here :) I'm gonna try to keep it general, cuz I think once you've got the basics down you can just watch some games and refine it from there. Also, I learned a lot of stuff about the game by playing video games like The Show, so if you can get a copy of that and wanna get more in-depth that's actually not a bad way to come at it from a different angle.

Let's start with the overall structure of the game. One of the things that's different from most sports is how many games there are in a season, and to accommodate that two teams will play several games in a row against each other. That's only really important if you don't want to look silly when talking to another baseball fan. As far as actual game structure, there are nine innings a game. Each inning has a "top" and a "bottom;" in Major League Baseball the away team gets to hit in the top of an inning and the home team defends ("fields").

Arguably the main competition happening within a game is between the pitcher and the batter. Whenever a batter steps up to take his swings, that's called an at bat or AB for short. During an AB, the batter will try to swing at pitches in what's called the strike zone. The strike zone (and correct me if I'm wrong on this guys cuz it has changed some) is the width of home plate and the height is between a batter's belt and his knees. It's important to understand the strike zone because then you can understand balls and strikes. A ball is whenever a pitcher throws outside the strike zone and the batter doesn't swing at it. However, if a batter does swing and either misses the ball or fouls it off, it counts as a strike. A foul is when the batter puts the bat on the ball but it goes out of bounds. This can be into the seats, behind the batter's box, outside the foul lines (those little white lines that go straight out from home plate, cross third and first base, and extend all the way to the edge of the outfield), etc.

The total number of balls and strikes in an AB is called the count. The count's important because once a batter gets 4 balls, he takes first base on a walk, which is also called a "base on balls" in ye olde lingoe and why the stat is abbreviated BB. But if the pitcher throws him 3 strikes, he's out! That's called a strikeout. However, a foul ball never counts as a third strike, it's only a strike out if the batter doesn't make contact (either swinging and missing or not swinging at a pitch in the strike zone).

There are other ways to record an out too; strikeouts are by far the least common. First let's talk fly outs. That's when a batter gets the ball in the air but it's caught by one of the fielders. There are two "special" fly outs, one being a pop fly. That's just a fly ball that doesn't leave the infield (i.e. usually it's caught by the pitcher or a baseman rather than an outfielder). There are also foul outs. Like I said before, fouls are balls that aren't in the normal playing field. But pretty much all stadiums have what's called "foul territory," which is space between the foul lines and the seats. If a fielder catches a fly ball that stays out of the seats, that's a foul out! Second, though, there are ground outs. A ball is considered "live" as soon as it touches fair ground. All that really means is that the batter-cum-runner isn't out yet. Anyway, if the batter hits the ball on the ground, one of the fielders can pick it up and throw it to first base. If the ball gets to the base before the runner does, he's out!

Obviously if every batter got out all the time the game wouldn't really have a point, so there are also hits! There are really only four flavors of hits: Singles, doubles, triples, and home runs. As the names imply, it's just what base the runner can manage to get to safely. If there's a runner on second or third base, we say he's in scoring position, which means that any hit has a pretty good chance of getting him home. Incidentally, that's how points or runs are scored: having a runner cross home plate.

A batter is credited with a run batted in (RBI for short) when he gets a hit and a runner makes it home. There are other ways to get an RBI, too: If there's a runner in scoring position (usually third base but sometimes second if the guy is REALLY fast) and the batter hits a fly ball far enough into the outfield, the runner can still score if he tags up and runs home. Since the ball hasn't hit the ground, it's not live yet. Once it hits the fielder's glove, though, we're off to the races! The runner first has to tag the bag he's on, then when the ball comes alive he can score. If he does, then the batter is out but he still gets an RBI. However, the fielders have a chance to throw the ball home and try to tag the runner out before he touches the base.

There are other sacrifice plays besides the sac fly. Batters can also hit sacrifice ground balls, but these aren't always to score runs like the sac fly is. Explaining this part requires a lot of strategy talk so I'll steer clear of a lot of it since I'm just trying to go through the basics, but a lot of the time it's just to move a runner into scoring position.

I'll finish out by just talking about a couple of the stats you'll hear a lot about. Ima start with hitting stats! The most common one you'll hear is batting average or just "average." This stat is just what percent of the time a batter will get a hit. Also, even though a lot of these stats are shown as decimals, they're really percentages. So like if a batter has a .250 average, chances are he'll get a hit every fourth AB. If he's got a .333 average, it'll be a third of the time. So on and so forth. If a player is batting over .300 that's generally considered really good. Jose Reyes right now has a .350 average and that's the highest in all of MLB, so that's really good. As an historical note, batting .400 is kind of a mythical achievement that not too many guys have managed.

I've already explained RBIs, but just FYI that's the other big stat that most media outlets highlight as the most important one. Home runs are usually the third stat that rounds out what they show you on TV when a guy steps up to bat. It's becoming more common, though, that a player's on base percentage or OBP is displayed. That's the average number of times a guy gets on base either by hits, walks, or being hit by a pitch (if a pitcher hits a batter with the ball the batter automatically gets to take first base no matter what the count is). Some people consider OBP to be the most important stat, but that's something you can read more about if you want.

And now here are some pitching stats! Probably the two biggest stats commentators highlight are earned run average or ERA and wins. The ERA is the average number of runs that pitcher would allow in nine innings. Say, for example, his ERA is 3.00. That means, were he to throw all nine innings of a game, he'd give up 3 runs on average. Anything lower than that is usually considered pretty elite. Wins are becoming more widely regarded as kind of a meaningless stat but, nonetheless, can be a big impressive number we like to ooo and ahhh at. The stat itself is just if one pitcher gave up fewer runs than the other. That's kind of a gross oversimplification, but I'm not sure I can really articulate the nuances much better than that. The pitching equivalent of OBP is the WHIP, or walks plus hits per inning pitched. I say "equivalent" because both are stats that are really important but only just starting to be talked about during an average broadcast. WHIP is a really crucial stat because it reflects how many baserunners the pitcher allows during an inning. A WHIP of less than 1.00 is suuuuper good, but becoming more common in the post-steroid era.

And with that, I think you should more or less have the tools you need to start watching and loving baseball! Welcome again!

EDIT: Wow thank you guys so much for the great feedback!!! This is my last day at my tearing-my-hair-out internship so I'll come back and change the things I got wrong later tonight. If you know of somewhere else where people might find this helpful, feel free to repost it wherever (though I'd really appreciate it if you tack my name on it)!

Buying him computer hardware might be nice, but there's a lot of other ways to give something related to games and game design.

There's always a great big pound of dice. It's full of dice of assorted numbers of sides, and a game designer remotely interested in tabletop (which should be all of them) can use a healthy supply of dice for making tabletop games. There's always the fun of just rolling dice giant handfuls of dice. I'm out right now but I'll add the link when I get back home. Here's the link: Pound of dice

I'd also look into games he hasn't tried. BoardGameGeek has a lot of board games listed and reviewed that you could get, and of course there's always steam. For board games I'd recommend:

• Red Dragon Inn, a fun party game for 2-4 that's best with 3+. You play as a bunch of adventurers after big dungeon raid and now they're spending gold at their local tavern and gambling. Can support more players with its sequels.
  
• Monopoly Deal: A card game version of Monopoly, without the bullshit. Unlike it's big board game cousin, it actually plays out fairly quickly while still being focused on building monopolies to win the game. As a game player perspective it's a fun game, but also from a game designer's perspective it's interesting to see how this game re-imagines the original board game while being true to the source material and streamlining many of its game mechanics.
  
• Carcassonne: A well known classic game that works well with 2-5 players where players build up a world of castles, farmland, and roads.
  
• Bang the Dice Game: A game where the sheriff and his deputies face off against the outlaws but nobody knows who to shoot. At the start of the game players are given their roles in the conflict but only the sheriff shows who they are. The rest of the game involves social deduction to try to figure who everyone is supposed to be shooting, and trying to read past bluffs. The game works great for 5-8 players, and can work for 3-8.
  
  There's also a lot of books on game design you can get him. You may have to check to see if he owns some of these already, but I've found them to be great reads that I can recommend to anyone interested in game design.
  
  
• Blood, Sweat, and Pixels: This is a book that tells "The Triumphant, turbulent stories behind how video games are made" and talks about the stories behind 10 different games from across the video game industry and what went on during development. I just bought this one and haven't gotten to chance to read it yet, but I'm excited to start it soon.
  
• The Art of Game Design: This is one of the most well known books on game design that discusses a lot of what makes games work. I recommend it to anyone interested in game design.
  
• Game Design Workshop: A Playcentric Approach to Creating Innovative Games: This book talks about everything that goes into how to design a game and some key differences on how some types of games work. It's more on the beginner/intermediate side, so some of it might be familiar to him.
  

> give a vague impression that they all do the same thing.

Lots of tooling does overlap but each one has one area it excels at - some excel at the same area.

---

So, you have done a good job so far, it seems like most of your stuff is automated to a good degree and you have identified where your weaknesses are.

You should tackle one thing at a time, identify your largest bottle neck or problem and work to solve that first. In the same vain, only introduce one new tool at a time. Each takes some time to learn and to implement it correctly. Trying to do too much at once will just cause problems.

You have already identified the weaknesses so focus on solving these, starting with what you think is causing the most issues.

> - One server per environment is obviously not super scalable

Look into HA setups. How you do this and how much work it is depends on your application. Typically there are two parts to applications, work and state. Work (such as processing requests) is easy to scale if it contains no state. Just add another server to the environment and load balance between it. For this you need a loadbalancer (HAProxy or Nginx work well, though there are many others to chose from) and to move any state off the node you want to scale.

There are many forms of state, most will be stored in a database but you should also pay attention to session state which is sometimes stored in memory on the node - if you have anything like this you will need to do work to move it into some sort of storage, like a database or storage solution (such as your existing database or redis or memcached etc).

> - No sense of automatic provisioning, we do that "by hand" and write the IPs to a config file per environment

There are loads of tools to help with this.

Terraform for provisioning infrastructure.

Ansible or Chef or Saltstack or Puppet for provisioning nodes (I recommend starting with ansible, though any of them will work).

There is nothing wrong with using bash scripts to glue things together or even do provisioning while you learn to use these tools. I would not shy away from them, but do recognize the benefits each tool provides over just bash scripts. Take your time to learn them and stick with what you know and what works for you while you do. Introduce them a little bit at a time rather than trying to convert your entire infrastructure to use them in one go.

> - Small amounts of downtime per deploy, even if tests pass

This is easiest if you have a HA setup. You can do it without one but it involves just as much work and basically follows the same steps as creating a HA setup. In short, with multiple nodes you can upgrade them one at a time until everything has been upgraded. There are always some nodes running on either the old or new version so everything will continue to work.

You can either update nodes in place, or create new ones (if you have automated their provisioning) and delete the old ones when the new ones are up and working (see immutable infrastructure for this pattern, also canary deploys and blue/green deploys for different strategies).

> - If tests fail, manual intervention required (no rollback or anything) - though we do usually catch problems somewhere before production

Tests should be run before you deploy. These should run on a build server, or ideally a CI system. Ideally these should not only run before all deployments, but also for all commits to your code base. This way you can spot things failing much sooner and thus fix them when they are cheaper to fix. You also likely want to expand on the number of tests you do and what they cover (though this is always true).

Rollbacks should also be as easy as deploying the old version of the code. They should be no more complex than deploying any other version of your code.

> - Bash scripts to do all this get pretty hairy and stay that way

Nothing wrong with some bash scripts, work to keep them in order and replace them with better tooling as you learn/discover it.

---

I have mentioned a few tools here, but there are many more depending on exactly the problems you need to solve. Tackle each problem one at a time and do your research around the areas you have identified. Learn the tools you think will be helpful before you try to put them in production (ie do some small scale trails for them to see if they are fit for purpose). Then slowly roll them out to your infrastructure, using them to control more and more things as you gain confidence in them.

For everything you have said there is no one solution and as long as you incrementally improve things towards the goal you have you will be adding a lot of value to your business.

For now you need to decide on which is the biggest problem you face and focus your efforts on solving that - or at least making it less of a problem for now so you can focus on the next biggest problem. Quite often you will resolve the same problems in different, hopefully better, ways as you learn more and as your overall infrastructure, developmental practices and knowledge improves.

---

Also the 12 factor app is worth a read as is googles SRE book and the devops handbook. The Phenoix Project is also a good read.

Though these are more about the philosophy of DevOps, they are worth a read but wont solve your immediate issues. Reading around different topics is always a good idea, especially about what others have done to solve the problems you are facing. It will give you different perspectives and links to good tools you can use to solve the problems you face.

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!
  

TL;DR Google "Cost of Delay", Puppet's 2016 State of DevOps Report page 43 for rework calculations, and compare %C/A improvement to increased %Innovation (%I).

This has been a major challenge opportunity for us. I would start by aligning the conversation to Agile Principle #1's three main tenants: Customer Satisfaction, Valuable Software, and Early and Continuous Delivery. If you are in a large (and old) IT organization such as mine, these tenants are loosely held to, barely understood, or simply dismissed. However, in order to measure the success of a digital transformation, these three things must be measured. For the sake of our VSM effort's MVP, we've focused on measuring Early and Continuous Delivery. (You can also discuss this in the context of the 3-ways of DevOps. Early and Continuous relates to the first way. Customer Satisfaction and Valuable Software are feedback loops of the second way. And getting us there is the third way.)

For our first pass at measuring Early and Continuous Delivery, we discussed how we could reduce total cost of change by reducing overall lead time (LT). A simple calc is team member count * hourly rate ($/hr) * 6 hrs/day * overall LT in days. You can get specific and do that calculation per value stream process block and add it up, or keep it high level and you'll be in the ballpark - off by 10-15% at the most. If you're working in hours, then you can adjust the formula by dropping the "6 hrs/day" part. (If you're working in minutes, you should just make the case for purchasing Google Nap Pods or something. =))

The problem with relating overall LT reduction to a cost of change reduction is it's not completely accurate unless the lead time and process time (PT) are the same. So LT = PT + QT. And unless we propose that queue time (QT) is spent doing nothing related to other value-add work (which would be tough to argue), then really the PT is the total cost of change. (I'd imagine we'd both agree that context switching has some non-value-add overhead, but how much? Maybe 10%?)

What we've found is that if we're talking about reducing overall LT the best measurement to catalyze the improvement conversation is to consider Cost of Delay (also check out here and here). You can show that by reducing overall lead time, we can capture the first-mover advantage, thus reducing or eliminating Cost of Delay. We are in a competitive capitalistic market after all. Our business measurements are relatively immature, so we used hypothetical numbers to demonstrate this. Obviously real numbers would be more impactful.

Next, consider %C/A. Rework (aka waste work) is potentially one of the biggest wastes of IT budget (and more importantly a development team's time) that a VSM can capture - a low %C/A is most certainly creating rework. Check out page 43 of Puppet's 2016 State of DevOps Report as it provides a simple calculation for rework cost. It may also be important for the group creating the VSM to perform RCA on a low %C/A process block as this may actually be the principle constraint of flow.

Moreover, a %C/A problem in Production has a direct impact on Customer Satisfaction. Framing improvement work with a risk-based mindset will inform you that solving a low %C/A problem in the Prod process block has a measurable impact on Customer Satisfaction. (Two before and after short surveys to your customers, internal or external, should show a diff in Customer Satisfaction if the %C/A in the Prod process block is improved.)

The last point is more of a qualitative measurement, and that is around %Time for Innovation (%I). I hope your organization doesn't devalue development teams as I have seen from time to time, but remember, development teams contain some of the most creative and capable women and men in the entire company. It's important that they move away from doing work a machine can do through automation and focus on innovative (aka creative) work. If you research HP's printer firmware transformation, you'll see that they related %C/A work (warranty) to %I. It makes sense that if the team is not doing rework, then they have time to focus on innovation. While this doesn't directly relate to Agile Principle #1, it will likely map to Customer Satisfaction and/or Valuable Software, since %I time can be spent doing A/B testing, spiking new and relevant technology, or simply interacting with customers directly thus gaining empathy for their jobs to be done.

I also highly recommend Accelerate: The Science of Lean Software and DevOps. The first part gets into some numbers and is essentially targeting middle management and up. It will give you some scientific foundations for some of these improvement conversations.

The business justification of VSM and improvement work is a big subject, and I'm still learning. Remember that finance is as much art as it is science. I hope this gives you some ideas!

I posted this in another thread so sorry its just a copy paste, but very relevant---


I dont recommend bartending school. i haven't been personally, but you dont need to pay for the education if you work at the right bar. I learned everything while getting paid.

Death and Co makes amazing books to teach and inspire how to make great unique cocktails. The modern classics covers the fundamentals of bar tools and all the philosophy, plus theres a bunch of neat recipes. They also have a codex thats super interesting in that they simplify and break down the origins of most cocktails. Everything is a riff on a classic, in one way or another.

Another one I like is from Smugglers Cove in San Fransisco (i think?) This book touches more into tiki and tropical cocktails, but its a lot of fun and there are plenty of great cocktails without super esoteric ingredients.

On the opposite end of the relax tiki book is this book from Grant Achatz, 3 Michelin starred chef of Alinea in Chicago (hence the pricy book). He also owns bars in Chicago and New York, and have some of the most exceptional drinks I've ever had. He's big on molecular gastronomy, wether its juice filled caviar balls, dry ice used to chill your drink tableside (with lots of smoke) or this tableside infusion. A lot of it is super over the top and not necessary, but for presentations sake its incredible. really innovative and inspiring

Sorry for the lengthy post, but I suggest that if you want to get into cocktails and mixology, find a nice restaurant with a cocktail program. If you're near a big city, try bar backing at a nice cocktail spot or restaurant, it'll help you kind of see things from the outside for a bit and will make it all less daunting.

cheers

This is going to be the opposite of what you want to hear. But, you asked for it and I respect that. I think that there's no substitute for going about this old school and traditionally. The good news is that you can mostly do this for yourself, by yourself.

If you're disinclined (due to time or for another reason) to enroll in a culinary program get yourself either The Professional Chef or Martha Stewart's Cooking School

I know what you're thinking, "Martha Stewart? What am I? A housewife from Iowa?" Fuck that. I've been fortunate to have met and worked with Martha Stewart she's smart enough to know what she doesn't know and that particular book was actually written by a CIA alum and very closely follows the first year or so that you'd get in a program like that. It starts with knife work and then moves on to stocks and sauces. This particular book has actually been criticized as being too advance for people who have no idea what they're doing so, despite appearances, it may be perfect for you. If you want to feel more pro and go a little deeper, get the CIA text but know that it's more or less the same info and frankly, the pictures in the MSO book are really great. Plus, it looks like Amazon has them used for $6 bucks.

These resources will show you HOW to do what you want and they follow a specific, traditional track for a reason. Each thing that you learn builds on the next. You learn how to use your knife. Then, you practice your knife work while you make stocks. Then, you start to learn sauces in which to use your stocks. Etc. Etc. Etc. Almost like building flavors... It's all part of the discipline and you'll take that attention to detail into the kitchen with you and THAT'S what makes great food.

Then, get either Culinary Artistry or The Flavor Bible (Both by Page and Dornenburg. Also consider Ruhlman's Ratio (a colleague of mine won "Chopped" because she memorized all the dessert ratios in that book) and Segnit's Flavor Thesaurus. These will give you the "where" on building flavors and help you to start to express yourself creatively as you start to get your mechanics and fundamentals down.

Now, I know you want the fancy science stuff so that you can throw around smarty pants things about pH and phase transitions and heat transfer. So...go get Harold McGee's On Food and Cooking THAT is the bible. When the people who run the Ferran Adria class at Harvard have a question, it's not Myhrvold that they call up, it's Harold McGee. While Modernist Cuisine always has a long, exciting complicated solution to a problem I didn't even know I had, when I really want to know what the fuck is going on, I consult McGee and you will too, once you dig in.

Another one to consider which does a great job is the America's Test Kitchen Science of Good Cooking this will give you the fundamental "why's" or what's happening in practical situations and provides useful examples to see it for yourself.

Honestly, if someone came to me and asked if they should get MC or McGee and The Science of Good Cooking and could only pick one and never have the other, I'd recommend the McGee / ATK combo everyday of the week and twice on Tuesdays.

Good luck, dude. Go tear it up!

Also, I had no idea that there was a huge, amazing world of fruit out there until I tried raw vegan & then fruitarian (currently omnivore, for the record, but still enjoy all types of good ingredients & recipes!) & started digging into varieties & sources a little bit deeper. I pretty much had stuff like apples, oranges, and bananas growing up. Fruit was good, but nothing to get overly excited about...maybe you got a really delicious orange once in awhile, but that was pretty much it, haha! But thanks to international shipping & market demand & places like Whole Foods & Trader Joe's trying to introduce more options to consumers, we have access to more global foods than ever before!

On a tangent, on a fruitarian diet, avocados & tomatoes are actually both included because they are fruits. They kind of fall into the sub-category of "fruit vegetables", along with zucchini, peppers, eggplants, pumpkins (yup), olives, pickles, and paprika (...berries). We eat a lot of Haas avocados in the United States, but they're not even the best ones - there's Reed, Fuerte, etc. But Haas makes more sense for market purposes (the smaller size fits more to a box, they ship better due to thicker skin, etc.), so that's what we get!

That's not a bad thing, however - it's really nice to have avocados available year-round, and even though they're kind of pricey (upwards of $2 each now, where I live), you can use them for so many things... chocolate pudding, Sinh tố bơ (Vietnamese avocado shakes), homemade ice cream (sounds weird, tastes good! I make it with coconut milk & cocoa powder sometimes). My buddy has an epic guacamole recipe available here:

• https://www.reddit.com/r/SalsaSnobs/comments/a3kjdy/the_only_guacamole_recipe_youll_ever_need/
  
  Also, there's a whole crazy world of crime, wars, and corruption that goes on to support the fruit industry. Check out Season 2, Episode 1 of "Rotten" on Netflix ("The Avocado War", 56 minutes long), for example. There are a bunch of great books on the banana as well, , such as "Banana Wars" & "Banana: The Fate of the Fruit That Changed the World". But enough tangents for one thread, haha!

I'm mostly a basketball guy so...


You don't need to have ever seen a basketball game to appreciate these first two books.

Breaks of the Game by David Halberstam which it probably the best NBA book. It follows the 1978 Portland Trail Blazers and gets way more access than anyone could get now. Plus Halberstam was a great writer so he gets the most out of excellent material.

The Last Shot by Darcy Frey this is probably my favorite basketball book. It follows high school basketball players and it works as biography as well as an exploration of sports culture, race, class, and youth. The Hoop Dreams of books. Great journalism on a great subject.

Freedarko's The Undisputed Guide to Basketball History Captures the visceral and intellectual thrill of watching basketball better than any other book. Manages to capture big picture and little picture.

Seven Seconds or Less Lifelong basketball writer follows one of the funnest teams in NBA history for a year


Pistol Biography of Pistol Pete and his insanely driven father. Manages the rare feat for a sports biography of not slipping into hagiography.


Baseball

Moneyball How baseball teams were run a decade ago. Really well written and somehow manages to make baseball and business really entertaining. Great for fans and non-fans.

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
   
   

• [Kanban: successful evolutionary change for your technology business] (https://smile.amazon.com/Kanban-David-J-Anderson-ebook/dp/B0057H2M70)
  
  
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
  
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
  
  As you may notice, the latter 3 books are mostly about how to quickly and reliably ship software. Developer workflow is a big part of getting that to happen, and many people have some of the same problems we do.
  
  I could go on like this for hours because I fucking love kanban. Feel free to PM me if you want to chat about your specific problems. There is figuratively nothing that I would rather talk to internet strangers about.
  

1.)We have the History. We have 9 World Series titles, which is a lot, (3rd all time) but not to a point where we are spoiled.

2.)We are one of the two teams in the AL that hasn't changed our names.

3.)We are on the West Coast, and for 10 years had a minor league team in Vancouver

4.)We are invented, and are Moneyball

5.)Nerdpower

6.)We have a great young bunch of players coming up that thanks to brilliant people, will continue for years to come.

7.)You can't beat us, everyone loves the underdog, and our uniforms are some of the best.

8.) We won 3 straight WS in the 1970's with one of the craziest teams of all time. The only other team to win 3 straight WS titles? The Yankees. Trust me, you don't want to root for the Yankees.

I hope now you have enough info to make a decision!

Edit-Spacing

Entrepreneur Reading List

1. Disrupted: My Misadventure in the Start-Up Bubble
   
2. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
   
3. The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It
   
4. The Art of the Start: The Time-Tested, Battle-Hardened Guide for Anyone Starting Anything
   
5. The Four Steps to the Epiphany: Successful Strategies for Products that Win
   
6. Permission Marketing: Turning Strangers into Friends and Friends into Customers
   
7. Ikigai
   
8. Reality Check: The Irreverent Guide to Outsmarting, Outmanaging, and Outmarketing Your Competition
   
9. Bootstrap: Lessons Learned Building a Successful Company from Scratch
   
10. The Marketing Gurus: Lessons from the Best Marketing Books of All Time
    
11. Content Rich: Writing Your Way to Wealth on the Web
    
12. The Web Startup Success Guide
    
13. The Best of Guerrilla Marketing: Guerrilla Marketing Remix
    
14. From Program to Product: Turning Your Code into a Saleable Product
    
15. This Little Program Went to Market: Create, Deploy, Distribute, Market, and Sell Software and More on the Internet at Little or No Cost to You
    
16. The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
    
17. The Innovator's Solution: Creating and Sustaining Successful Growth
    
18. Startups Open Sourced: Stories to Inspire and Educate
    
19. In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters
    
20. Do More Faster: TechStars Lessons to Accelerate Your Startup
    
21. Content Rules: How to Create Killer Blogs, Podcasts, Videos, Ebooks, Webinars (and More) That Engage Customers and Ignite Your Business
    
22. Maximum Achievement: Strategies and Skills That Will Unlock Your Hidden Powers to Succeed
    
23. Founders at Work: Stories of Startups' Early Days
    
24. Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant
    
25. Eric Sink on the Business of Software
    
26. Words that Sell: More than 6000 Entries to Help You Promote Your Products, Services, and Ideas
    
27. Anything You Want
    
28. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers
    
29. The Innovator's Dilemma: The Revolutionary Book that Will Change the Way You Do Business
    
30. Tao Te Ching
    
31. Philip & Alex's Guide to Web Publishing
    
32. The Tao of Programming
    
33. Zen and the Art of Motorcycle Maintenance: An Inquiry into Values
    
34. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
    
    

    Computer Science Grad School Reading List
    

    
    

35. All the Mathematics You Missed: But Need to Know for Graduate School
    
36. Introductory Linear Algebra: An Applied First Course
    
37. Introduction to Probability
    
38. The Structure of Scientific Revolutions
    
39. Science in Action: How to Follow Scientists and Engineers Through Society
    
40. Proofs and Refutations: The Logic of Mathematical Discovery
    
41. What Is This Thing Called Science?
    
42. The Art of Computer Programming
    
43. The Little Schemer
    
44. The Seasoned Schemer
    
45. Data Structures Using C and C++
    
46. Algorithms + Data Structures = Programs
    
47. Structure and Interpretation of Computer Programs
    
48. Concepts, Techniques, and Models of Computer Programming
    
49. How to Design Programs: An Introduction to Programming and Computing
    
50. A Science of Operations: Machines, Logic and the Invention of Programming
    
51. Algorithms on Strings, Trees, and Sequences: Computer Science and Computational Biology
    
52. The Computational Beauty of Nature: Computer Explorations of Fractals, Chaos, Complex Systems, and Adaptation
    
53. The Annotated Turing: A Guided Tour Through Alan Turing's Historic Paper on Computability and the Turing Machine
    
54. Computability: An Introduction to Recursive Function Theory
    
55. How To Solve It: A New Aspect of Mathematical Method
    
56. Types and Programming Languages
    
57. Computer Algebra and Symbolic Computation: Elementary Algorithms
    
58. Computer Algebra and Symbolic Computation: Mathematical Methods
    
59. Commonsense Reasoning
    
60. Using Language
    
61. Computer Vision
    
62. Alice's Adventures in Wonderland
    
63. Gödel, Escher, Bach: An Eternal Golden Braid
    
    

    Video Game Development Reading List
    

    
    

64. Game Programming Gems - 1 2 3 4 5 6 7
    
65. AI Game Programming Wisdom - 1 2 3 4
    
66. Making Games with Python and Pygame
    
67. Invent Your Own Computer Games With Python
    
68. Bit by Bit

Let's go ahead and jump down the rabbit hole here.

1 - Reddit is a business. It's a subsidiary of Advance Publications. Technically any content or comments you post here are unpaid contributions to someone's bottom line. Controversy and lies are amoral in this context, meaning that if something gets hits and views it's gold. Doesn't matter if it's bullshit feminism, a post about some cool archaeological dig in Siberia, or a post hating on mods and admins. Even this box I'm typing is gifted content.

2 - The internet itself is a fucking business. And it's about as cultish as you can get. Memes, viral videos, comment circlejerks, flaming, are all part of a "cult"ure we've built around the rights and wrongs of interacting with each other through electronic means. Anything desirable but "other" is quickly categorized and integrated. Anything undesirable is simply ignored. That means controversial is actually desirable because it generates back-and-forth. This dynamic is super fucking easy to manipulate, meaning...

3 - It's all marketing now. When companies exhaust their technological or practical advances, they turn into marketing machines. And those machines are as vicious as they are effective. Just try reading more than half of Trust Me, I'm Lying: Confessions of a Media Manipulator without wanting to throw your computer and phone in the trash and move into the mountains. If you post in an online forum, you're becoming part of 100 problems at once. You can weigh the pros and cons and decide against participating if you like.

4 - People trying to market and make money off of PUA, Red Pill, or anything else are as varied as any other self-help group. Some are completely full of shit. Some are so-so. Some are downright fucking necessary and totally worth your money. Now the ones that are worth the money and time, I want them to have exposure and visibility. I want them to have a voice that effects others because that means eventually I'll hear about their awesome idea, read it, and change my life.

5 - Just because you engage in a few activities in a community does not mean you're in a cult. I've seen real cults hidden off in the backwoods, actual physical groups of people that truly indoctrinate their youth with mantras like "I beat my body and make it my slave." It might be scary to think that people go into those things without any critical thought, that they become automatons for some fake "greater good."

But I'm going to go off the rails here and say: Why not?

Why not drop your ego sometime and join up with a group that demonstrates effective methods of self-development? I remember being invited to a secret meeting of a Christian teen group off in the woods where they had an "Honor Ceremony." Basically these kids had worked their asses off studying and working out in pure isolation. They learned about God and all that stuff - to each their own - but the end result was a group of extremely committed, extremely in-shape young adults.

I mention this ceremony because the message was not what I expected from any Christian sermon anywhere:

(paraphrasing) "The moment you leave this place, everyone is going to want to have sex with you." That was their graduation message, and it wasn't a lie. These kids had been holed up away from civilization and honed into fit little soldiers of Christ and then told the most honest thing ever: the outside world would find them hot and innocent. They would be irresistible.

So maybe some become lifelong Christians. Some get into drugs. Some, like the girl I took back to my dorm (they kicked her out after she spent a weekend with me), just fast-tracked from slut to married life and forgot the place altogether. Basically it all evens out. The cult thrives off of those few who both become successful and maintain their beliefs. Everyone else is just forgotten.

I personally think Red Pill is most effective when it feels like a cult for the first little bit and then once you get past the basics and realize it's about living your own life and thinking for yourself, you realize the entire fucking message is do what you want. If you want to join a cult, sure. If you want to climb a tree and piss on people on the sidewalk, great. As long as it's your decision apart from the "oh man are other people judging me" voices, it's still your life.

We're in the opening stages of buying out a large company. Similar sized (international, thousands of employees, dozens of sites all over the place) to us; but naturally there's months of procedure before the buyout is complete. Gov't approval, shareholders vote, board voting, etc. I'm not allowed to communicate with my counterparts at the incoming company, but have contacts in other industries that do business with both of us. I got word a couple weeks ago that their entire team in a specific IT specialty is quitting. They're all scared that my company is going to fire them all as soon as the ink dries.

First off, nothing could be further from the truth. My company may be an outlier, but we do lots of M&As every year; tempted to say 1-2 a month. Mostly small shops, but every now and then we bag a big one like this. Vulture capitalism is a real thing, but it makes up a very very small amount of buyout and mergers. You're still right to be scared, people are always fearful of change. Buying a new house/car, moving to a new place, taking a new job, etc. Perfectly natural.

I'll take a minute to hit on your core concerns:

> Everything I look after is old

So what? If the old hardware is still meeting its requirements in the production environment, that's fine. It's nice to have newer stuff, but I've never seen management update hardware simply because it was "old". If it was constantly at risk of losing customer data, or had unsolvable security concerns, then upgrading it to newer hardware would make sense.

About 1/3rd of my environment (+1500 servers) is what I would call ancient.... but they're still running. Supporting apps that customers use. Preforming some special process that needs specific hardware/software. In some cases, the team that owned the hardware was divested years ago and nobody told us to turn off their shit when they left. It kinda common. During the merger process, everything will be inventoried and documented, including what the server is actually doing (ie: hosting). This is where the curtain is lifted and suddenly we don't need to keep all these boxes running. The ones that do need to stay will get P2V'ed or V2V'd to better systems, if there's a reason it can't stay in its current environment.

> I get the feeling we're kept here temporarily to keep the old stuff running.

Yes, of course you are. Who else? Your team has the knowledge and experience keeping it all running. You're kinda stuck in a holding pattern though. Until the merger is complete, you can't get a job at the new company, and you can't move up at your current one. If you quit your job, you wont get a place at the new company, even if you fit the bill.

At my place, we do very little external hiring, and even then only for esoteric positions (IE: Lync Engineer, Sharepoint admin, Citrix, etc). M&A's are the primary source of our onboarding. Not just because you have experience with the current systems that the company is inheriting as part of the merger; but because you've played an important role in making your current company attractive to mine, which is what lead to the buyout. If your IT systems were shit, and always crashing/losing data, your company wouldn't have grown to the point where it'd be attractive to buy it out. Also, you're keeping these ancient systems running? Nice... obviously you know what you're doing.

Which brings me to the next part... have you met anyone from the new company's HR team yet? We always send in a team of people (directors, HR, advisors) to meet with the employees of the newly acquired company. Figure out who are the good apples and who are bad. Who knows what they're talking about and who is just faking it for the paycheck. If you haven't met with the other company yet, I'd strongly advise you to not jump ship yet. You could be throwing away an excellent opportunity just because you're scared of the pending change.

> Management is off-site.

This is perfectly normal. My manager is 1000mi away, and I only talk to him over Lync/email. Somehow we take care of all our datacenters, around the world, without having to see each other in person. But hey, this is the 21st century and this is how it works. The best people for the job may not live within 50mi of your office, but are within range of another office. If you need someone sitting in the same building to give you guidance on what needs to be done, then you need to ask yourself why. It shouldn't matter if your orders come over an email, a voicemail, or a sit-down meeting. In my experience, having remote management makes the subordinates much more responsible. They're allowed to get their job done their way, in their time (as long as it meets the metric of success), and then report success over an email/chat/call. Almost everyone I've met loves this kind of system. Much more laid back then say, a micromanaging boss who hovers over your desk and asks for constant updates.

> Pay is low, turnover rate high

This too is normal during your M&A. Accounting doesn't want to introduce extra financial liabilities for the new parent company, because it can throw off their forecasting models. Don't be surprised if you get the bare minimum until about ~6mo after the ink dries on the merger. This applies to new hardware, facilities requests, bonuses, perks, etc. It's not a bad sign... but it can be bad for morale. My suggestion is to just suck it up, because you're not going to win a fight with the accountants.

> Change management is more strict.

Get used to this in larger companies. Can you imagine the chaos of hundreds/thousands of people with their hands in thousands of servers? If a customer app goes down at 9am without CC, how do you figure out who did what where? Was it the app owners doing a code change? Was it the network team upgrading a switch? Was it security rolling out an update to the firewall? Change control saves your ass. I was befuddled by the process too when I started, but they've made a believer out of me.

Why should the company wake up 100 people in the middle of the night, to play Sherlock Holmes in the environment, looking for what has changed, because some developer made an opps?

[Also, if you've never read The Phoenix Project, I strongly recommend it. It'll give you a look at how a company without change control "tries" to get things done, and then you can see how change control, once properly implemented, makes everyone's lives soooooo much easier].

> What to do?

Nothing you've done at this point has been unreasonable. Like I said before, your reaction to the change in your company will naturally cause feelings of fear, anticipation, anxiety; which leads to second-guessing and the sense of flight. Your paycheck is at risk, which puts food on the table, gas in your car, and a roof over your head. Totally normal to be up late at night wondering what the future holds.

I'd suggest you get your CV updated... and also put together a portfolio. If/when the new company comes to visit, they'll want to meet with the team who has kept everything running and see if they can be integrated into the new company. You're not re-interviewing for your current job a la 'Office Space', they want to see if you can provide extra value to the company if given the chance. This is where you impress them with how you saved the day keeping X-system online, or how you automated something that used to take days, into minutes. Things like that.

I would NOT suggest signing a 1yr committal on a new lease with the intention of staying with the company. My advice is from someone who has sat on the other side of the table, and while I'm painting you a rosy picture because you've given me no reason to think less of you.... I will state that someone people will be laid off. Duplicate positions, fakers, incompatible team members, etc. Not everyone makes the cut. If you're a decent worker who can be taught new tricks, odds are on your side of being "asked" to join the new company (where you'll still do your current job, and take on more responsibility for a while, until we can find a way to reduce your criticality to the old entity).


tl;dr - Fear of uncertainty is normal. You don't have the full picture of what's going on behind the scenes. You'll see the writing on the wall IF layoffs are coming. Don't do anything rash.

I have read so many books but I got most of them from the library years ago and they are probably all out of fashion. I think this one from Amazon is good despite the fact it's geared towards larger flocks. The length is right for a comprehensive guide (400+ pgs) and cage design and development is discussed.

One of the reviews links to a book geared towards smaller flocks which only gives one cage design and skips over things like slaughter. That's not necessarily bad but I have always found more information to be better, which is why the library is awesome.

The tone is more lightweight in backyard or urban chicken books. Which can be good depending on the audience. Again, my only complaint is that this tends to lead to skipping information which may be valuable. I have no problem with people keeping their chickens as pets but I am not a fan of books which skip over the less pleasant details to appeal to that audience. While they may sell like hotcakes, the readers are just sticking their heads in the sand because they find certain authors distasteful.

No matter what design you choose here are some ways to keep your flock safe:

• Put them into a completely wood enclosed coop at night. Critters can't break down wooden doors.
  
• Don't forget to open it up in the morning, especially if it's hot!
  
• When you let them out of the cage watch the skies as well as the ground. Hawks like chicken for dinner too. Keep them under the trees if possible.
  
• Critters can dig under chicken wire, plan accordingly. Rocks and closed coops are your friends.
  
• Wire gets old, check on it once in a while. I have lost a few chickens because raccoons and skunks checked for me instead.
  
  I hope that helps :)

As you're both (you and the team) very new to scrum, you should start with some of the supporting basics that help tie everything together.

You're pretty far from the ideal situation, but there's nothing preventing you from learning and growing together. it's much harder without a careful guiding hand, but not impossible. There's a lot of things you're not going to know/understand simply because you haven't been exposed to it yet.

1. Always begin with why. Why do we have planning. Why do we have BL grooming. etc. by understanding the purpose of each ceremony you will be able to better understand how to execute these ceremonies against the context of your organization.
   
   IE: scrum doesn't have a set way to do these ceremonies (other than loose guidelines. the by-the-book approach) because how they are run is environment specific. Most places are not equipped to do scrum by-the-book exactly. IE: they have QA. and QA is not a role within the scrum framework. The team should clearly define the roles and responsibilities of each team member. These definitions will change over time through the retrospective. every standard, process, etc. should be treated the same way. you should always be verifying that your processes are still valid. As the team matures and grows their needs will change and your processes should reflect that.
   
   
2. The loose guidelines are a starting point. these are not an end-goal. IE: in the retrospective we typically ask three questions: What should we start doing, what should we keep doing, what should we stop doing. you answer these questions in the context of product (what you're working on), process, and people.
   
   However this is a 'crutch' for teams that don't understand the retro yet. this format should eventually change, but you won't have to worry about this for a while.
   
   
3. do everything you can to understand the basics of software development. (IE: things that should be done independently of Scrum) These are things like understanding the 5 levels of estimation, the difference between relative and absolute estimations, why the team needs to establish standards for processes and definitions (IE: definition of done, when should something be a task vs a story), the difference between data and information, roles and responsibilities, etc.
   
   This is the kind of stuff that really differentiates between a scrum master/agile coach and a project manager.
   
   
4. Also understand that Scrum is an agile framework. Just like the 3 question approach to the retrospective, scrum is a stepping stone to becoming agile. If you haven't, you should read the original HBR article about scrum to get a better understanding of the strengths and weaknesses of the framework. this should help you understand the 'why' behind each ceremony and allow you to better make adjustments based on your environment.
   
   6 months to a year from now, what you're doing should look different than scrum by-the-book. I highly recommend you start reading books to help cover the gaps in your understanding. I suggest you start with Phoenix Project and a book on writing user stories.
   
   
5. Think of scrum as a problem finding mechanism and not a problem solving mechanism. This is why the retrospective is the most critical ceremony of scrum. DO NOT WORK AROUND PAIN POINTS. If the team says they feel like they have too many meetings, figure out why. If something took longer than expected, dig into what dependencies were missed in planning and take steps to make sure those aren't forgotten again.
   
   The point of a sprint is to iterate. Yes, we also get shippable increments out of a sprint and that's important, but this pales in comparison to iterating against your product (so you can fail faster and get more value to your customer) and your own development process (this is what will truly enable you to iterate faster and faster as you mature)
   
   This means you will often but heads with leadership, as better development practices often require a shift in culture. Ultimately you want to be able to have autonomous teams that are aligned to the business needs.
   
   -----------------------
   
   Recomended reading:
   
   https://hbr.org/1986/01/the-new-new-product-development-game
   
   https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509
   
   https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909/
   
   https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/
   
   https://www.mountaingoatsoftware.com/blog
   

It is a little unusual for the whole flock to wait two weeks. But, Ive definitely had individual birds wait that long.

With the rain it sounds like they just arent getting enough sunlight. Like others have suggested you can put a light in and keep it on for 14 hours a stretch. I would leave the tarp up. Im in Texas so we dont get as much rain but even here if it rains it makes the hens....pissy...and they dont lay for me either those days :P To be honest unless you need the eggs right now I would just wait for the rain to pass and let them get used to the weather where they live.

But you know this is where animal husbandry kinda gets more into the art instead of the science. Everybody has to decide whats the best for their chickens in their yard given the information. Like, these are things that work for me but see in Florida you may never get a time when the rain lets up and so it would make sense to have a light in the coop. You can always try it. (of course be careful with electricity and rain)

If youre letting them into your yard, on top of feeding them chicken feed, they are most likely getting all the nutrients they need.

Yeah I would put some boxes in their coop. Ideally you want them so you can access them from the outside. The first coop I built I didnt do that and most of the hens figured out on like the second day where to lay so I had to crawl in to get the eggs.

It sounds like youre taking really good care of your chickens. Really I wouldnt worry too much right now.

One of the books that I got when I first got started is this one. It was just technical enough and just common sense enough to get me going. Of course this is a really good subreddit too!

Hi! Sorry for the delay, I wanted to answer this correctly (and I'm happy to discuss it further).

> If anyone else than Symfony created a HTTP client, I would argue you wouldn't have answered with the same level of questioning.

Agreed.

> it means Symfony has a reach and people expect high quality packages coming from it.

Yes high quality is a criteria, but it's not the one thing. I think the key here is the impact: Symfony has a lot of weight in the community.

> But it's also a shame, because it tends to demotivate people trying to innovate. When everyone is asking you to justify every single action you do, you tend to stop because you're tired, especially if you do it for free.

Understood, sorry about that. I'll try to be careful about the way I say things.

The thing is that it's hard discussing some topics, and this is something I see often: either you say nothing (and avoid any risk to hurt or displease anyone, or even look like a fool), either you speak, but you need to find the right words and formulate it in a constructive way.

I want to speak about this topic because I care. And because most developers I am discussing with are unhappy as well (but none of them is saying much). I find it disheartening to see this (given how Symfony is important and used, and how many people work on it - including for free as you said), and my goal is to share this in the hopes that things change somehow. I am not looking to dismiss anyone's work.

Now let's try to discuss the actual topic:

I agree that it isn't just about Guzzle vs Symfony's new component, or even PSR-18 (which is why I don't think it's worth discussing specifically about this). A few facts:

• Symfony left the FIG, and before that wasn't really involved anymore for some time
  
• Symfony reimplemented some projects that existed and were used by the community (Guzzle is another example, but another example that comes to mind is DotEnv)
  
• Symfony Flex changes how Composer, the most standard thing in PHP, works
  
• Flex recipes are controlled by Symfony in a repository (whereas Composer is an open thing)
  
• the PHPUnit bridge highjacks PHPUnit's behavior (again, one of the most standard package in PHP)
  
• some new components are discussed "in private" and announced to the community, where it used to be discussed openly before
  
• (I'm stopping here because you get the point)
  
  Now I hope I portrayed these as facts (and I may have some of them wrong). I completely understand that many of these things happened because of good technical reasons.
  
  But if you look at it from what "it looks like": Symfony seems to be aiming to be a closed ecosystem. Symfony used to be the open framework, built upon reusable components and compatible with any PHP library out there. Now it feels like things are changing (note I am talking about a feeling, it may actually not be the case but that's what some people feel). For example some people believe that the next step for Symfony is to reimplement Monolog as a component (and possibly ditch PSR-3), and the next step would be Doctrine. Same goes for API Platform. Personally I think it's possible that this may happen.
  
  And things can change, it's fine, but here it seems like it's a whole change of identity. And I think that's why some people feel uncomfortable, and that's why as well it's so hard to voice (because it's intangible).
  
  Lately I've been reading Start with why and it explains it very well. Nobody complains about Laravel releasing stuff in a closed ecosystem: that's what Laravel is about. It's part of its identity. Symfony's identity has (from my perception) always been different: more open, more about the community, etc. Maybe it's time to redefine clearly the Symfony identify (and explain that it's changing)? Maybe it's just a communication issue? I don't think it's a technical issue in any case.
  
  Anyway as you can see it's not easy putting words on all of this. But to reiterate: I'm talking about how some people feel (to give concrete number it's between 5 to 10 people). And I feel like it's worth talking about it because I care about the Symfony and the PHP community. I hope that helps!

I could have swore I replied to this, but I guess my comment got lost because I keep like, fifty fucking tabs open at a time. My bad.

ahem Anyway, it's hard for me to say if my taste differs much from an NT's sense of taste. I do feel like I taste things with more complexity(?), but I don't have much to compare it to. I can say that I started learning to cook and bake after reading and memorizing large portions of [The Professional Chef] (http://www.amazon.com/Professional-Chef-Culinary-Institute-America/dp/0470421355) and people love my food. And I taste-test it throughout the cooking process to make sure it's good, so apparently there's nothing wrong with my sense of taste. Maillard is one of my favorite words.

I hate the taste of liquor in things. I like alcoholic drinks where the taste of alcohol is completely disguised.

My favorite food is ice cream. My least favorite food is caviar.

I'm picky about the textures of foods, and I can't eat anything that smells bad (like kimchi). My sister-in-law makes this Filipino soup with tamarind and cellophane noodles that absolutely disgusts me. The smell of it drives me from the house. (Don't tell her I said that.)

I have a very strong sense of smell, which I think makes my sense of taste stronger than the average bear, but I'm not sure. I do know that certain smells which bother other people (skunk, gasoline, burning rubber, a catalytic converter) do not bother me at all. I actually think they smell pretty good. Meanwhile, some things which people think smell good (like certain flowers and perfumes) smell awful to me. I CANNOT go near a Bath and Body Works store.

I love to try cooking new and exotic things, but I personally have very simple tastes. I could happily live the rest of my life taking in nothing but coffee with milk and sugar, iced sweet tea, iced water with lemon, plain turkey sandwiches on white, and Campbell's chicken noodle or tomato soup.

Cilantro tastes like cilantro to me. Not soap. :D

Not OP, but I asked the same question years ago and I compiled this list:

​

1. This is the best book on the subject that I've read. It is as fair to both sides as one can be. In fact, I came away with a better understanding of how and why the Palestinians feel the way that they do after reading the book.
   
   ​
   
   
2. The Arab Spring. This is a great journey through all of the countries affected by The Arab Spring. It helps understand where we are now.
   
   ​
   
   
3. The Prize. Technically, it is the history of the oil industry. As you should expect, it covers a lot of ME history, too.
   
   ​
   
   
4. Black Flags: The Rise of ISIS This book helps you understand how radical ISIS really is compared to AQ.
   
   ​
   
   
5. Michael Oren has two good books: Six Days of War and Power, Faith, and Fantasy. Despite Oren's affiliation with Israel, his books are fair and interesting reads.
   
   ​
   
   A book on the fall of the Ottoman Empire is another good place to start. I have not read this one yet. I've heard that it is a good read.
   
   ​
   
   ​

I sort of am on the fence of recommending these books but have you read?

• Phoenix Project link
  
  
• Art of the Start link
  
  
• The hard Truth link
  
  Learning how businesses work definitely improves your tech skills. It helps build logic based around what is best for the business, not what is best for IT, or what is best for you. Learning how IT becomes a finely tuned oiled machine for your business is even better.
  
  I have read some of the books on start ups and business so I can understand where they come from, what they are trying to accomplish as a business.
  
  The soft skills will come as you work with more and more people. Just always try to walk into a situation as a neutral part, listen, observe, learn and don't be a jerk. The soft skills will develop pretty easily that way

Hey there!
UX Designer/Researcher here. I came from a background in Psychology and Neuroscience research before UX Design. Personally I used the UCSD Extension for a certificate in UX Design. I really appreciated the course work and in conjunction with the Coursera Interaction Design felt like I was given plenty of exposure while also having flexibility to work.
From my experience in the industry, I would look into what area you are interested in. UX careers can involve programming and development, but I use absolutely no coding at my current position (at others I have though). The biggest selling point to an employer is showing an understanding of the process: wireframes, flow charts, user studies, iteration (agile/scrum/waterfall), and design understanding. I have worked on multiple billion dollar webpages and can say the process is nearly identical when scaled down.
If you are interested in some resources to start on your own I would recommend Simon Sinek's Start with Why for understanding how to look at design solutions.
Don Norman has many great books, including The Design of Everyday Things.
Some actual books to look at and learn on your own are A Project Guide to UX Design, Lean UX, and The UX Book. I highly recommend the last one I find it very thorough and digestible and for ~60 bucks is a reasonable textbook.
Lastly, once you have a grasp of UX as a concept I would get familiar with the Adobe Suite, Axure or InVision, and any others from career sites that you might not know about (I really like [Sketch]() as a cheap option ~$99).

Best of luck, feel free to ping me with questions

Sounds like you're well along the path to becoming a crazy chicken lady--welcome aboard :)

Honestly, you don't need most of the stuff on your list. Chickens need an off-the-ground roost in a predator-proof space to sleep, access to water and food, a safe place to lay eggs, and that's about it. Feel free to go crazy with extra perches in the run, toys, mirrors, swings, etc. but don't feel like they are necessary. My chickens have far more fun digging through a big leaf pile than any other amusement I've devised.

Your chickens may have issues learning to use the treadle feeder. Mine have yet to manage it, so I changed to using a hanging feeder for the rodent resistance.

Sand as litter is controversial, with some bloggers claiming it's the best and easiest and others claiming it's unhealthful. You probably want to switch to what's sold in the USA as "builder's sand" rather than "play sand". It's coarser and much cheaper, and less likely to cause respiratory distress.

On constructing a dust bath: I'd only recommend this if they don't have access to dirt in their run. I meticulously created a beautiful dust bath in a sawed-off wine barrel, with the so-called perfect mix of sand and dirt, but my hens literally never used it. They preferred to dig their own dust baths in their run's litter or in my yard.

One optional addition is Storey's Guide to Raising Chickens; I'm not sure how much overlap there is with the book you already have, but Storey's is excellent.

I'd also consider buying nest pads, though you can just use wood shavings.

I personally find sweet PDZ to be helpful, and if you're using sand as litter (I use deep litter) you'll probably find it even more so. It absorbs ammonia, odors, and moisture.

Oh wow, great question! I've pondered this quite a bit and am currently reading up on two resources to deepen my understanding:

Stripe's Developer Coefficient report: https://stripe.com/files/reports/the-developer-coefficient.pdf

Accelerate: The Science of Lean Software and DevOps: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

It's kind of a wordy title for that book, but it's interesting to see what the authors deem to be the really key things for safely accelerating development velocity. We've addressed a lot of the things in the book via intuition over the years but I really would love for us to start being more methodical and process oriented in trying to improve things. I'd be interested to hear what you think!

I'd love to have some metric that represented how "sure" developers feel when they are developing new services/features and estimating timelines as well as how "sure" they are about deploying changes without having unplanned reverts and things of that nature.

The problem is that click-bait is the only way to keep the lights on for most of these sites. They just don't make that much money.

Consider how this translates to employee pay and, in turn, the incentive for these employees to pursue virtuous journalistic careers and invest the time required to keep things on the straight and narrow.

As a result, we don't get journalism - we get op-ed and clickbait. We get toxicity.

This is part of a vicious cycle. Toxicity and clickbait are more profitable.

It is in human nature for us to have our interest piqued by negative headlines and bad news. Our brains work by recognizing patterns and relationships between facts and situations. We've evolved to be more interested in the facts that jut out and are potentially more threatening to our survival.

So, bad news and negativity gets clicks. Weird-ass headlines gets clicks. Misinformation drives clicks. Toxicity drives traffic. Clickbait drives traffic.

Go look at the headlines and "hot" articles on top gaming blogs. You'll see tons of negative articles or headlines that stir toxicity.

• The more people get upset, feel that they're getting taken advantage of, or feel threatened, the more likely they are to click.
  
  
• The more inflammatory the article, the more likely people are to comment.
  
  
• The more likely they are to comment, the more likely they are to return to the article.
  
  
• The more likely people are to return to an article, the more page views the blog gets.
  
  
• The more page views the blog gets, the more they make.
  
  So, if you're the editor for a gaming blog site, what do you do? Even if you're not intending to run toxic content, you might unconsciously start becoming conditioned to run toxic content through the positive feedback you get through page stats.
  
  In systems like Forbes where anyone can submit and the most popular articles get featured, it's easy to see how the most divisive and potentially toxic content gets featured.
  
  Consider this. Here's a fictional made-up quote we can use for the sake of argument.
  
  > "In the new game, the brothers go to Africa. It's a fascinating place," said Jim Drawerson, artist on Super Plumber Brothers 2. "It was hard to capture all of the culture and ethnic diversity, but I think we did a good job."
  
  Which of these three headlines do you think will get the most clicks and comments?
  
  > 1. Super Plumber Brothers 2 artist interview
  
  > 2. Super Plumber Brothers 2 artist talk about setting game in Africa
  
  > 3. Super Plumber Brothers 2 artist slammed for racist comments
  
  For the third headline, all you have to do is find a few people on Twitter who were offended (someone is always offended about something), screenshot their comments, and paste them into your article.
  
  The third headline will drive clicks, even if it's not accurate. But who's going to hold the gaming bloggers accountable?
  
  Gaming blogs are largely not accountable to anyone except the stats that keep the doors open. I'm not going to name names or sites, but I can tell you that, having worked in the industry, there are a handful of very popular sites that do not fact check and do not run corrections. It should come as no surprise that these sites also make most of their revenue on click bait.
  
  So what can we do?
  
  
• Do not click on clickbait. Look at the headline of an article and ask yourself - Is this going to help me understand or know more about gaming?
  
  
• Do not comment on inflammatory articles. This only gives toxic clickbait more views.
  
  
• Question sources. What are the facts that the author is asserting? Where did they get these facts? Did they talk to the developer/publisher?
  
  
• Question credentials. Who wrote this article? What is their qualification? What kind of articles do they typically write? Have they contacted the publisher/developer to get the facts?
  
  
• Question authority. Who is writing this? Do they have special knowledge? Do they have special access?
  
  
• Tell authors and editors when you see clickbait and you don't like it. Do this through Twitter - not through the site. Do not contribute to toxic comments sections.
  
  
• If you find a factual error in an article, tell the author. Do this for Twitter. They will probably censor you in the comments section.
  
  
• Comment on articles that are well-written and contain facts and thank the author.
  
  It's a huge effort, but a lot of the toxicity in the gaming community comes from ignorance. And that ignorance is driven, willfully or not, by clickbait.
  
  
  At the end of the day, there's just not that much gaming news. So someone has to stir up drama to fill columns and drive clicks.
  
  EDIT -- This is a great book that covers some of this subject matter. Very quick read.
  
  http://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285
  
  To be clear, I am not affiliated with this book and am not using Amazon affiliate to make money on clicks/purchases of this book. I think it's a great resource for people who would like to know more about this topic.

Not quite. The banana in the supermarket is known as the Cavendish banana, a sterile cultivar. It has no seeds, which is much more appetizing than the alternative. The species Musa acuminata is the progenitor of sweet bananas. The edible bananas we know and love are triploid hybrids. The ones with mostly Musa balbisiana genes are plantains, essentially.

As Wikipedia notes, when the two species were introduced into the same range, they started hybridizing, giving us our delicious banana without all the seeds. When people noticed this, they started growing those more and more. It was a happy accident, and humans started growing them, just like any other crop.

Note that this is just a quick summary, and I encourage you to read more about it. The banana has a pretty fascinating history, and Wikipedia's articles are great places to start.

EDIT: Wow, thanks for the gold! For more information about bananas, check out the book Banana: The Fate of the Fruit that Changed the World by Dan Koeppel. To get an idea of what the book covers, here's a podcast between Steve Mirsky of Scientific American and the author. It will blow your mind.

Get this book. I picked it up before I got my first chick and it taught me everything I needed to know from egg to old hen.

My first chicken was a Speckled Sussex and she was the best girl I ever had, friendly, smart and not flighty at all. Other breeds that have been easy for me: Orpingtons, Barred Rocks, Easter Eggers, Brahmas, Welsummers, and Barnevelders. Silkies are cute, but they are always the dumbest chickens of the flock it seems like. I would say the variation isn't so bad that you can't just get the breed of chicken you like best for whatever reason: egg color, egg production, feather pattern, etc.

Chickens can tolerate quite a bit of heat (with basic shade and lots of water), and quite a bit of cold (with shelter from the wind and friends to huddle next to). I would think you probably don't need anything special in SW Missouri, but if it looks like your mom's chickens are in extreme discomfort, there are ways to help them out then.

The most important thing is to make sure the coop is completely secure and protected against predators. The #1 cause of death for my chickens has been raccoons.

Good luck to your mom!

My favourite books about growing cannabis are:

• True Living Organics (2nd Ed.) by The Rev
  
• The Cannabis Grow Bible (3rd Ed.) by Greg Green
  
• Marijuana Horticulture: The Indoor/Outdoor Medical Grower's Bible by Jorge Cervantes
  
  These books are quite comprehensive. As you may already suspect, True Living Organics is primarily about building living, organic soil, and the techniques that the author uses to maintain the soil and maximize the quality of the end product.
  
  The Cannabis Grow Bible covers all things related to growing cannabis, as well as producing extracts. Very comprehensive and an excellent tome for any grower to have, from wide-eyed novice to salty veteran.
  
  I have an older edition of Marijuana Horticulture from the early 2000s, and use it quite a bit less than the other two, but it was very useful to me when I was starting out. I would recommend The Cannabis Grow Bible first and foremost, however.
  
  I hope this helps! Don't get overwhelmed by all the information out there; best thing I can recommend is to pop a few seeds and just give it a go. Don't let your inner perfectionist prevent you from attaining perfection through time and experience!

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

Depends how much effort you want to put into it.

For general baseball knowledge and history:

• Watch all of Ken Burns Baseball (its all on Youtube).
  
• Read Moneyball for an understanding of how modern analytics revolutionized the game and upended the status quo. (Some people are still fighting this fight, but among MLB front offices the nerds have already "won" basically).
  
• Read Baseball Between the Numbers for a good primer on modern analysis (though there has been more progress since that book came out of course)
  
  
  For Dodgers specific history:
  
  
• Watch the ESPN 30 for 30 on Valenzuela (Fernando Nation).
  
• Read Jon Weisman's book about the Dodgers for a great overview of team history.
  
• Read Molly Knight's book for a good narrative look at the current team and ownership group. This is great context for understanding how we got to where we are now.
  
  For current news and analysis:
  
  
• Dodgers Digest is a great blog for level-headed, intelligent Dodgers analysis. The writers there know what they are talking about and aren't overly reactionary, as a general rule.
  
• True Blue LA, the Dodgers SB Nation blog, is run by Eric Stephen who is the most diligent Dodgers beat writer today. In the off season for example, he's writing a season review for every player who appeared for the Dodgers in 2015.

Another "lunches" book to read after the first is Powershell Toolmaking in a month of lunches there's another book coming out on the matter of Scripting later this year.

Also, for reference see if you can get Powershell in Action

It was written by the man who architected and designed the bloody thing, so you're in good hands. I've not read it cover to cover, but it's certainly the definitive reference on the subject.

All above books rated 5/5 stars on amazon by a lot of people.

If you're so bogged down, stitched up and scared to even think about automating anything, then I'd absolutely recommend The Phoenix Project this is the paradigm shift IT has gone through over the past decade. Essentially, IT has taken on board efficiency and best practices that have been standard in the manufacturing industry for decades, to incredible success.

Seriously, "Bag of Nails" IT shops are on their way out. If they're that unwilling to take a step back and do things the smart way, they're a shit company to work for. Learn about technical debt and why it's critical to pay it off.

DevOps and Site Reliability are in essence the latest buzzwords in IT service management, but there's a lot of positive change going on in the industry off the back of it. There's a sort of productivity Gold Rush.

If you're bogged down your current job sounds like the perfect place to cut your teeth and leapfrog off the back of it to move into a better organisation who wants to work smart.

Have fun!

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.

There is a wonderful book about process improvement from about 35 years ago called The Goal by Eli Goldwater that is written as a novel. Wonderful book - terrible novel: The Goal: A Process of Ongoing Improvement https://www.amazon.com/dp/0884271951/ref=cm_sw_r_cp_tai_AS.vDb6F2QH3T

And The Phoenix Project - on DevOps is an homage to The Goal and is also a novel: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win https://www.amazon.com/dp/1942788290/ref=cm_sw_r_cp_tai_9Y.vDb2981BYS

Also an amazing book and a terrible novel. Both of these are great examples of the power of different learning styles. The novel format accommodates Socratic Learning (questioning) and is just a terrific way to teach what would otherwise be very dry subjects. Humans are wired for storytelling and these books are exemplars of that.

Okay, so my recommendation is similar to many others here, except that I'd say start with(get an audible subscription),

The Goal Audio Book by Eliyahu M. Goldratt

This is a really good book to start with, reasonably easy to listen to in audio format once you get rolling. It all started with this book! It's perfect start before you seque into

The Phoenix Project

It made for a pretty descent audio book as well. I powered through both of them while commuting. And I found it to be good enough.

DevOps HandBook

This however isn't quite as good as an audio book and you are better off with the book itself unless you are tight on time.

From there, this primer is pretty comprehensive to get you rolling,
[O'Reilly Learning Path: Modern DevOps] (https://www.safaribooksonline.com/library/view/learning-path-modern/9781787280236/) which will cover a little bit of every technology you might be interested in. I haven't gone through this myself but it seems to have descent coverage, from the 3 ways, to git, containers, docker, kubernetes, ci(jenkins), swarm, aws, puppet, salt, testing, agile, compliance, etc etc..

As everyone else has mentioned, 12 Factor is a required reading.

And if you want a pretty deep dive on Docker, Docker Mastery: The Complete Toolset From a Docker Captain

Is well maintained. If you want to know AWS better, there are some descent udemy courses as well that you can pickup for $15. Anything from Ryan Kroonenburg is pretty descent. Side note Azure just started offering a managed kubernetes service that is now in preview its worth checking out.

From there, the only other thing I would say is to look at Terraform and every product by hashicorp and some more in depth content for
kubernetes and possibly Powershell if you are a windows person.

I don't know of any that compare, but, the Napoleon's Buttons is SUPPOSED to be good.

http://www.amazon.com/Napoleons-Buttons-Molecules-Changed-History/dp/1585423319/

Other books, engineering related, that I liked are:

Norm Lieberman's Process Troubleshooting books, the guy cracks me up!

Working Guide to Process Equipment (3rd edition probably cheaper): http://www.amazon.com/Working-Guide-Process-Equipment-Fourth/dp/0071828060/

Process Equipment Malfunctions (not as good as the other one, some overlap, but still worthwhile, and covers more breadth for individual issues): http://www.amazon.com/Process-Equipment-Malfunctions-Techniques-Identify/dp/0071770208/

The Prize (mentioned above): http://www.amazon.com/gp/aw/d/1439110123/ref=redir_mdp_mobile/188-3799228-4803548

The Quest (Follow on to The Prize): http://www.amazon.com/Quest-Energy-Security-Remaking-Modern/dp/0143121944/

Oil 101: http://www.amazon.com/Oil-101-Morgan-Downey/dp/0982039204/

The Mythical Man Month (Not engineering directly as it pertains to software, but, projects and project management are huge in engineering, though this book is timeless): http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/

Piping Systems Manual (You can NEVER know enough about pipe!): http://www.amazon.com/Piping-Systems-Manual-Brian-Silowash/dp/0071592768/

Pumps and Pumping Operations (OMG it is $4, hardcover, go buy now! This book is great... did you know OSU didn't teach their Chem E's about pumps? I was flabbergasted, gave this to our intern and he became not a scrub by learning about pumps!): http://www.amazon.com/Pumping-Operations-Prentice-Pollution-Equipment/dp/0137393199/

Any good engineer needs to understand MONEY too:

The Ascent of Money: http://www.amazon.com/Ascent-Money-Financial-History-World/dp/0143116177/

It's Nial Fergesuon, who has had his own series of dramas and dumb stuff. The Ascent of Money has a SLIGHT libertarian tinge... but it wasn't bad enough that I didn't enjoy it. I consider it a history book, and he attempts to write it like one.

Have fun!

I think one thing to do is not only get your kid into the athletic side of sports, but also to the career or academic side of it. Rather than encourage your kid to be an athlete, you should be promoting the concept of becoming an athlete/coach or athlete/trainer or athlete/manager, etc.

Just having your kid trying to become the best athlete is very short sighted, and you're limiting the potential success of your kid through sports. Let's be honest, your kid isn't going to be the next Pacquiao. But he could become a great trainer with a bunch of gyms in the area he lives in, well connected to the boxing industry. He could become an executive or manager or trainer within the industry. You could have your kid learn math through sports for example. There's plenty of nerdy analysis in all sports, since Moneyball came out.

This book has been suggested a few times so I finally got around to reading it. I think it has some good information in it. I'm only about halfway through it, but I like it so far.

Time Management for System Administrators

Other books would be any of the social books like "How to influence people", "7 healthy habits..." Etc.

I haven't read this one yet, but It has been suggested to me if you plan to go more into management/leadership Start with Why

Other books that have I have ear marked due to being mentioned:

• The Devops Handbook
  
• The Practice of System and Network Administration
  
• The Practice of Cloud System Administration
  
• Cognitive Behavioral Therapy - This one might have been a joke, but as someone who has dealt with depression and burnout on the job. I think this could be beneficial.
  
• How to win friends and influence people
  
• How to win friends and influence people in the Digital Age
  
  Also, do a search for "Books for IT Professionals" to find a lot of other suggestions.

Works pretty great if you're allowed the head count and coaching/training time necessary for full ownership of a product. Burns out all of your employees if you don't have those things :)

It's one of those things I've evangelized heavily within my organization -- my team is able to do it for all of the products we ship because we've been given the appropriate head count and time to maintain the standard. And it works great; MTTR for bugs and support cases around the products my team owns are significantly better compared to others within the company where they're totally out of the loop until it bubbles up from our support or TechOps folks. Translating that into dollars for executives and finance folks is trivial and so is doing an apples-to-apples comparison against the cost in engineering/maintenance/support hours versus MTTR for other products. It's just math, and if you're doing it right it tends to be favorable math.

But the head count needs to be allowed. The cross-training needs to be allowed. Favoring increased resilience instead of increased velocity needs to occur for a while. People with the right mindset of owning a product from creation to delivery are expensive. If you're on a quarterly profit cycle beholden to outside investors, the difficulty in arguing for these allowances is magnified significantly.

I enjoyed Accelerate's approach to answering those concerns.

I don't mean to hijack your comment, but I just wanted to say that every libertarian the slightest bit interested in the food-industrial complex, regulatory capture and regulatory consequences should read Everything I Want to Do Is Illegal by Joel Salatin, a self-described libertarian-environmentalist-capitalist-lunatic organic/sustainable farmer. Highly, highly recommended.

Also, Food, Inc. (featuring Salatin) is a good documentary; some of the implied solutions/conclusions are admittedly statist in nature, but there is nonetheless a lot of good information regarding the incestuous relationship between the State and the industrial/corporate food system. I first saw it at a documentary festival, and it was quite satisfying to see people applauding the scenes with a self-identified libertarian.

An excellent book for you at this point would be Jacques Pépin's Complete Techniques. From the description:

"Jacques Pepin's Complete Techniques features everything the home cook needs to perfect: poach an egg, whisk a perfect hollandaise, knead a crispy baguette, or bake an exquisite meringue with the perfection and efficiency of a professional chef. Featured throughout the book, Pepin's classic recipes offer budding masters the opportunity to put lessons into practice with extraordinary results."

It also covers things like knife technique and other fundamentals, which you mentioned.

As far as French cooking goes, although they've been around awhile, two books that are still definitive on the subject are Mastering the Art of French Cooking by Julia Child, Volume One and Volume Two. All three of these books (Pepin plus these two) are foundational to learning about cooking. There are others, but these will give you a very good start, and will increase your cooking skills and knowledge exponentially.

If those aren't enough, you can also check out The Professional Chef, which is a fantastic book of recipes and techniques put out by the Culinary Institute of America. It's a bit spendy, but worth it if you want to learn. The Amazon links are provided for reference; if money is an issue you can quite easily find all these books used.

I'm still a young C# developper, around 3 years of C# for websites and APis for small and big companies, but it's not because your predecessors built an in-house framework that this is the right way to build a system. C# is a great language but it shine thanks to the core orientation of productivity delivered by the .NET framework and ASP.MVC.


Of course if your needs are so specifics that you want a custom framework, don't forget that it will become a HR problem. Talented people rarely want to jail themselves to a company and build a specific set of skills that can't be transferred.


But as I said, I'm young. I do think that we are living on the shoulders of giants and that not everything need to be rebuilt. Some of the coolest techs we've seen these past years around containers and micro-services were actually already implemented in the 70's.

That said, I didn't read this book, so I will read it and predictably learn a lot of things. If you didn't already, I would recommend the following books. They aren't C# specific but will help you in the environment you are describing:

• [Working Effectively with Legacy Code] (https://www.amazon.com/gp/product/0131177052/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1)
  A mountain of pattern for common uses cases to improve stability and efficiency of legacy apps.
  
• [The Phoenix Project]
  (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509/ref=sr_1_1?ie=UTF8&qid=1498813798&sr=8-1&keywords=the+phoenix+project)
  An inspiring guide on how to work and migrate from waterfall project toward a more predictable project management methodology.

>Fine here's some math, Hellblade took 10 million to make and has only sold roughly 1 million copies, so the game sold at $30 would have made 30 million minus the 10 million and minus roughly 10-15% cut that Sony, Microsoft and Steam take from each sale. So that's close to a 20 million dollar profit, nothing crazy and nothing that would have Microsoft a ton of money to buy.

You still didn't answer my question. You merely did back of the envelope math of potential profit.

Let me repeat it for you:

> What is much (or not) to you?

..................

>Not really, there's a load of marketing talk but State of Decay 2 has fallen off the face of the Xbox Live's most played games at the time of writing this and before you start crying for a source here you go, if it's there by the time you see this maybe it'll have changed but I can't imagine by much.

Yet it exceeded MS expectations. Of course anyone can have "higher" expectation and proclaim it low. Heck, you don't have any hard numbers on that list. That is why it is called "relative".

> Not just critics but also developers,

What is that supposed to mean?

>No that isn't just an opinion, if you were to say the same thing in a court of law you'd be laughed out of the room.

The only one being laughed at is you right now. You don't know what contract work is.

>The same guy who said who said Sea of Thieves would be "2018's PUBG"? Sure looks like a completely unbiased journalist to me?

Yup, an opinion makes him unbiased. /s

Goes in line with your other "I can't imagine" things.

>No I'm pretty sure they could have sued for embezzlement if there was any, a similar situation happened with Sega and Gearbox with Alien Colonial Marines but Sega couldn't sue because technically Gearbox fulfilled there end of the deal, they completed the game and released the game on the agreed release date but Scalebound was never finished.

I don't know what to tell you man. If you told that in a court of law, you'd get perplexing looks of confusion at the stupidity of that statement. Video games are delivered by milestones. Look it up, Mr I know how it all works.

>So like I said, there's a clear line of communication between the Devs and Publishers and they're someone to ensure deadlines are met.

That has literally nothing to do with how much a studio and MS negotiates how much they are going to pay. A studio can literally say, I want 100 million or 10 million, and MS can ya, nor nay. Having a producer has nothing to do with that.

>You're one of the smuggest, most condescending people yet you're pathetically misinformed about basic steps in game design.

No, I just met somebody that makes a shit ton of assumptions and can't imagine any other way. It speaks more about lack of imagination than anything else.

>Source them.

Try this book, it's a great read: https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234

>Something presented without evidence, can be dismissed without evidence. Until you can provide something besides a flimsy rumor, I don't believe it.

Evidence is the rumor. Believe it or not, up to you. That said, I can say that about everything else you have said.

For instance, prove that Platinum Games spending money they earn on contract work on other projects is embezzlement. I'm waiting.

In fact, prove that GaaS makes all games bad and while you are at it, prove that the cost of purchasing Ninja Theory is not a lot.

>Plenty of games have tons of planned content and features axed and since Microsoft was willing to ax full video games in mid-development, it's not outside the realm of possibility for them to ax a gimmicky TV tie in.

Then you are thorougly confused about how video game development work. The TV tie in is a design pillar of the game.

>Again just saying "Your opinion" does invalidate my statement. Also I can fathom it, but it's literally the least likely scenario.

It does, because it is just an opinion. Not a universal fact. I can have an opinion as well. I like yellow. What color do you like?

https://www.resetera.com/threads/microsoft-studios-partners-current-and-future-landscape.1061/page-465#post-7839552

>Nobody refuted him? It's pretty easy to refute his Scalebound claim.

Please do so. Your opinion doesn't count nor does it serve as proof or evidence.

>So because people like these games and actively indulge in these practices make these practices any less scummy and predatory?

Yes, because they by and large don't complain. In fact, many of them actively embrace it. Just because you think it is predatory doesn't mean it is. We already established though, you thought RBS implemented it well.... Are you now backtracking and claiming it is predatory and hence bad?

> Oh I guess you just gave a pretty good argument for justifying most atrocities throughout history.

Depends on what you consider atrocity.....

https://www.amazon.com/Cannabis-Grow-Bible-Definitive-Recreational/dp/193786636X/ref=sr_1_1?crid=3N9MIBRHWTFAY&keywords=cannabis+grow+bible&qid=1569722339&sprefix=cannabis+grow%2Caps%2C205&sr=8-1

That should be your go-to. It covers everything basic and gives you a good starting point. With that book you'll be able to google problems you can't solve and have some idea of where to look and how to phrase your questions.

In-line fans are your savior. You don't need to vent out (for clarity, this is for smell. You'll need to do something about the heat). The goal is to cycle the air in the room through the fan. But also keep in mind that lights create heat and your plants like to exist in a specific temperature range and humidity. You will need some kind of way to cycle "fresh" air through your tent but generally a decent CFM fan will pull air from the main room.

Get a good tent that has decent sealing zippers and vents.

Drying in your tent is fine but you have to dry in complete darkness as light degrades your cannabinoids. So you'll have to put your grow on hold to dry, not a bad thing necessarily but it means potentially 2 weeks of not being able to do anything which cuts into a consistent harvest schedule. Consider curing is a few weeks too if done properly but that's done in jars and can be stored elsewhere.

Best advice, buy the book, read it and everything else you can about growing. Don't ask questions without trying to research it first. Every single thing you are questioning has been asked and answered online 100's of times. You will learn immense amounts of useful information (and learn to pick out disinformation) by reading through these posts. At that point buy your gear. It will save you a lot of time and money by having a basis before spending cash.

There's more than one way to grow cannabis, everyone thinks "their way" is the best. The truth is each method has it's advantages and disadvantages, do what works for you.

The big news here is that this particular strain of Panama disease has gotten out of Asia. It's not going to wipe out banana production overnight, but now that it's in Africa it could very well lead to hundreds of thousands of deaths due to starvation. There are a number of countries in Africa where families rely on a banana tree for an enormous amount of their daily caloric intake. While most of those countries don't use the Cavendish cultivar I believe a few of the most popular varietals are susceptible to this fungus. There are some that are resistant. I'm trying to remember which ones. I want to say the Brazilians have one that's tart and almost crunchy like an apple but the big companies don't want to switch to it because it's "too different".

There are also varietals that have a significantly higher quantity of vitamins and are all around more nutritious than the Cavendish, but again the major corporations, Dole and Chiquita, think the consumer is too unwilling to stomach a change in flavor or they themselves are unwilling to adjust their supply chain to accommodate more delicate fruit. My uncle actually grows the old Gros Michel or "Big Mike" that everyone used to eat. It's SIGNIFICANTLY better. It's got a thicker peel so it transports more easily and oh my god it's so creamy. There's actually a line of thought that the banana is the fruit referenced in the garden of Eden description which seems more plausible when you try the better varietals and lines up with where bananas were historically grown and eaten.

The sky-is-falling style rhetoric that accompanies this issue is a result of the frank inevitability of Panama disease shutting down industrial Cavendish operations. There is no way to stop it, currently they use incredibly harsh pesticides to slow it. The banana is uniquely difficult to genetically modify or even cross breed because any of the common edible versions deliver something absurd like 1 seed per 1 million fruit so the researchers are forced to either sift through that many bananas or more commonly they use current wild bananas which have massive seeds and then try to slowly breed the seeds out. It's a huge pain. Anyway the Cavendish is almost guaranteed to die unless there are some major breakthroughs in mycology. At the current rate, they're looking at 10-20 years max assuming no huge advances.

I recently read that book they referenced which gives a lot of fascinating detail about the history behind the banana industry and this particular fungus and where I got most of this detail. It's a fantastic read especially if you want to hear about the United States explicit backing of two major corporations as they effectively cripple central america in order to better control their labor. This book: http://www.amazon.com/Banana-Fate-Fruit-Changed-World/dp/0452290082/ref=sr_1_1?s=books&ie=UTF8&qid=1394076091&sr=1-1&keywords=banana

> You mentioned our GDP. 2/3 of our GDP comes from consumer spending.

Consumer spending and the output of the economy is impacted by how much people have to pay for gas, heat, oil, etc ENORMOUSLY(think about how much the average citizen spends on gas throughout a year and then think about them spending that on other things). Like I said you are uneducated in subject matters that are essential to comment on these matters and you are going to go on as if you aren't. All while arguing a position no analyst in the world would(hyperbole).

https://www.amazon.com/Ascent-Money-Financial-History-World/dp/0143116177/ref=sr_1_1?ie=UTF8&qid=1466453148&sr=8-1&keywords=Ascent+of+money

https://www.amazon.com/Prize-Epic-Quest-Money-Power/dp/1439110123/ref=sr_1_1?ie=UTF8&qid=1466453203&sr=8-1&keywords=The+prize

Read these two books and you will have a clearer picture of this macro picture I was referring to and you will understand how absurd your position is. The ascent of money was made into a pbs documentary, albeit a 4 hour one. It doesn't do the book justice though.

http://www.pbs.org/wnet/ascentofmoney/

The Prize was a Pulitzer Prize, non fiction book that will educate you on oil and why the middle east is important.

https://careers.state.gov/work/foreign-service/suggested-reading
Click on the suggested reading list on that page.

To get the whole macro picture I was referring to, read these books. You may want to start with their recommended International Relations textbook. These are books the State Department recommends you read if you are going to negotiate and do diplomacy on behalf of United States government(pretty hardcore stuff).


Best of luck with your studies/investigations and enjoy the rabbit hole, it really is an eye opener into another world that is not really discussed in the media.

Here's the thing with the Cubs, there are plenty of reasons for this prolonged title drought.

Chicago was the last team to move over to set up a farm system, ownership never spent a lot of money on payroll until the last decade or so, and they shared a division with one of the most successful teams in baseball; the St. Louis Cardinals.

The Chicago Cubs didn't win a title for over a century because they were doing everything to prevent a championship run for so long. Once they invested in the right people, right players, etc. they won a championship. In fact, stats pointed to the Houston Astros being the most cursed team in Major League Baseball prior to the Cubbies winning it all this year.

Here's a 2011 Chicago Tribune article that goes into greater detail on this. If you want to read further I strongly encourage reading Scorecasting that touches upon this and challenges, investigates other interesting topics in sports.

I'm reading Elon Musk's biography right now and think it might be helpful if you're talking about career success. The dude seems like a jerk but has an incredible work ethic and drive to succeed.

You can say pretty much the same exact thing about Augustus' biography.

Outliers really helped me a lot, because it made me realize talent wasn't nearly important as skill/effort. You put in the time and effort and you will develop your skills.

If you're an introvert like me these books helped me "fake it till I make it" or just want to be more socially capable: Charisma Myth, anything by Leil Lowndes, Make People Like You in 90 Seconds. Not a book but the Ted Talk about body language by Amy Cuddy

A book on leadership I always hear good things about but haven't read yet is Start With Why.

When Breath Becomes Air - Paul Kalanithi

Being Mortal - Atul Gawande

Better - Atul Gawande

Honestly anything by Atul Gawande

Start With Why- Simon Sinek (Just finished this one today. Phenomenal read. Not medicine related, but a great perspective on what leadership means and how you can inspire those around you)

The White Coat Investor - James Dahle (Financial literacy is always a good thing)

​

I have quite a bit more book suggestions if you're ever curious, but those should keep you busy for a while. Feel free to DM me if you want more!

Not sure if you can get Cachaca there, but the capirinha is a very 'beginner friendly' cocktail that's clearly international.

Seconding maximswim's recommendation on tiki cocktails, they're basically all strong and generally on the sweet side, plus they can have cool garnishes/mugs. If you're willing to do complicated drinks, Smuggler's Cove is a great resource.

I'll tackle some of the resources. As a Writer, I'm sure you'll appreciate some of these.

• Best book for tiki cocktails & rum, and a bit of history: Smuggler's Cove: Exotic Cocktails, Rum, and the Cult of Tiki
  
• Best book for tiki history: Tiki Pop
  
• Best website to peruse tiki mugs: Ooga Mooga
  
• Best bulletin board for general tiki culture: Tiki Central
  
• Best website for locating tiki bars and shops: Critiki
  
• Largest U.S. tiki convention: Tiki Oasis
  
• Web list of other tiki conventions: Tiki Festivals

> What is DevOps? Developer operations? What does does Dev ops imply?

What you are asking is a HUGE and complicated question.

DevOps is a dramatic change to the way the business operations unit and their technology teams interact to create technology solutions to support business projects.

Yes, DevOps involves a lot of software development skills. But it can also require technology infrastructure skills, and it DEMANDS the involvement of the business unit.

DevOps can be a real and very serious game-changer if a company is willing to invest in it.
It is growing steadily throughout the industry. Not explosive growth. Not leaps & bounds. But steady growth.

I STRONGLY encourage you to invest $15 into this book, and spend 6 hours plowing through it. (I read it in about 4 hours)

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

This is not a reference book. You will not search through it to jog your memory about how to do something.
But you very well might loan it to a bunch of people so they can learn from it too.

So, spending the extra money on the hardcover edition wouldn't be a terrible idea, but any edition is fine.

YOU need to read it once, and develop an understanding of the almost philosophical concepts. Then you're pretty much done with the book.
If your local library has it, that's even better.

This might also help:

https://en.wikipedia.org/wiki/DevOps

> What really fucks me off is the insistence on using a metric shitload of acronyms that are literally meaningless to a new spectator. It took me a fortnight to work out that K means strikeout. Why, for fuck's sake?!

It's actually because of Henry Chadwick, an Englishman who pioneered the statistical analysis of baseball. The "K" represents the last letter in "struck" (as in "struck out"). He used it because "S" was already taken up as a designation for "sacrifice" (as in "sacrifice hit"). It is still popular because baseball fans are creatures of habit, and, as others have mentioned, "K" makes it very easy when scorekeeping to differentiate between a swinging strikeout and a looking strikeout.

To address the broader issue: Baseball statistics have developed haphazardly over the last 150 years. Old statistics with old designations are layered under newer statistics with newer designations - all of them carrying little (or big) bits of information about the play on the field which, at one point or another, somebody thought it would be useful to remember - and the abbreviations and acronyms reflect the evolving requirements of newspaper layout editors, analysts, fans, and scorekeepers. There's really no easy way to learn it all, but I can assure you that just trying to do so will immeasurably increase your appreciation for the game.

I would suggest a two-pronged approach. First, take note of the statistics mentioned by broadcasters. These tend to be "caveman" stats - batting average, RBIs, ERA, pitcher wins, etc. - which are really crude measures of performance but are very popular and therefore are important to know. Second, pick up a book or two about sabermetrics - Moneyball and The Book are both good - and read a little bit about the more advanced approaches to stats and analysis that baseball watchers have taken over the past couple of decades. Also, surf Fangraphs and Baseball Reference. Soon, you'll be able to identify all the statistics that broadcasters throw around, and you'll be able to tell which of them are useful and which are useless.

Jason has connections all over the gaming industry. He even wrote a book about a few game developments: https://www.amazon.com.br/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234

He keeps posting on troubled development stories on Kotaku too (the Anthem and BO4 articles, for example). He earned my trust in regards for info in the game industry.

>"Italy is very similar to Greece in terms of climate and terrain (with some important differences), and classical Roman architecture took a lot of cues from Greek styles (again, with important differenes). Point being, they could re-use - if not the models - a lot of the same textures from Odyssey, cutting down on the amount of work they would have to do.
>
>It fits within the same era. AC games seem to usually run in series based on time period; you had the Ezio trilogy which hearkened back in Revelations to the first game; you had ACIII and Black Flag in similar eras (Edward was Connor's grandfather), and those plus AC:Unity, AC:Rogue, and AC:Syndicate are all within about a hundred and fifty years of each other (from 1715 at the start of IV to 1868 for Syndicate). Since they've been working in the ancient period with Odyssey and Origins, if they're going to do another game set in that era, it would make sense to do it immediately afterwards - and I don't think they're stupid enough to never make an AC game set in the Roman Empire."

I agree with your points. But at the same time, if we look at their situation right now....they surely will want a game that will be playable on old and new gen next year. So Montreal has 3 years to release it, right?

They surely will not want a brand new era/assets in a game that will have to release in both systems. In that case, they needed something that could use what they have in Origins/Odyssey. Of course, this would give points to Rome, which was something that even I was believing some time ago.

But then, Jason reports puts a wrench into the situation. And when you think about it...Vikings can fit very well (conquests battles, naval system, mercenaries, huge natural landscapes, etc) and also show a more medieval vibe after the 1 year gap, helping to fight series´s fatigue

And yes, I agree that the Roman EMpire would be fantastic. I was believing on AC: Legion a few months ago (at least we got the tittle in another franchise). Is it trully gone? Now that is another question. It would not be impossible to happen after Vikings. We had Odyssey and Black Flag happen right after 3 and Origins, so it would not be that weird for a prequel after a sequel.

The schedule is interesting if they do follow the current formula:

2013 - Black Flag (Montreal)
2015 - SYndicate (Quebec)

2017 - Origins (Montreal) - 4 years of development
2018 - Odyssey (Quebec) - 3 years of development

2020 - Kingdom (Montreal) - 3 years of development
202? - ??? (Quebec) - ? years of development

Will they skip 2021 and then have 4 years for their next gen title? Or only after 2021 will they skip a year and then having their first new era? That is up in the air for now. I think Ubi would give a lot of time for their next gen title and really nail it.

>You put a lot on the table but I'd rather just try to parse the core contention I have with what you're trying to say, which still appears to be "One is good enough to judge what's good"

No, I'm saying that "one should not be interested in the rank of an advice-giver."

>How are people like this, who represent the vast majority of the game, supposed to stress test anything and come to an honest conclusion? How will they interpret the results? My core contention with what you're saying, to use very plain terms, is people are dumb, and you appear to be saying that people aren't dumb and can think for themselves, but then at times you seem to admit people are dumb also.

I saw the first Men In Black movie too; people are dumb. But a person is smart. It's up to them to play through the solo queue grind, it's up to them to overcome obstacles in their path, and it's up to them to acquire the skills to get over those hurdles.

But why are people dumb? It's groupthink; what happens when people put acceptance of ideas over substance of ideas. That comes from fallacies, one of the largest being ad hominem/tu quoque. How'd the Democrats nominate Hillary Clinton? They convinced themselves that the biggest scandal magnet in US political history is the "safer" (more likely to win) candidate than Sanders. How'd the Republicans nominate Donald Trump? They convinced themselves that the guy who has talked more about his dick in public than every candidate in US history combined will inspire voters to get behind him.

How do low bronzies stay bronze? They're not thinking or improving, and it's probably because they're letting someone else do their thinking for them. Not certainly, but you see what I'm saying; thinking for yourself will be of help.

>It feels like I should be agreeing with you when I'm reading what you're writing, but i don't know what it is, I just end up confused. I just think you're putting too much stock in the fluidity of what's good and what's bad in this game. I'm super pragmatic about things, I'm not going to crunch the numbers on 4x dagger rush on ADC's. I'm just going to go "Whelp, whatever the standard build is is probably really good and refined, and 4x dagger rush is probably garbage. I just won't run the numbers on that and risk missing out on the epiphany that the playerbase has it all wrong.

You should. You'll be surprised at what you actually can learn.

Here's a piece I wrote with a very clickbaity headline where I theorycrafted an item choice. I believed then and still believe now that it was right at the time, but the items have changed since then which make the article wrong today. For example, it was written before the Refillable Potion existed.

Feel free to read the comments to see people shit all over it. But, pay attention to this comment string. A Diamond player takes me on, makes some very fair points, and has more to say when I rebut. His final point is along the lines of "I agree with your point that if you do these other things that you mentioned in the article, your item build is better. It's just not that clear-cut," and I found that to be a completely reasonable answer.

This is of course in contrast to this diamond player who has a one-word reply, and his follow-up is proven wrong in the article.

>This is just one instance obviously, but this is my general approach to the entirety of the burden of knowledge in League and what I'd advocate to just about anyone.

Yeah, this isn't a simple game. But, it's not chess or go. It's not that hard, nor is i hard to put in the time studying if you're already willing to put in the time playing. Now, if someone is adverse to self-study, that's on them. I just hope they're not surprised when they haven't actually improved several months down the line.

>Your tl;dr appears to be "Think for yourself" mine is "Listen and copy high elo players blindly" Both have their flaws, clearly, but this just appears to be a difference in outlook.

Yeah, your description of my point is accurate enough. And, I seem to be correctly hearing yours. I just disagree with it very strongly. It's come up too often in my own experience to see it any other way. I'll spare you my life story, but I can provide general evidence.

A software developer from India, who has watched cricket and nothing else, has volunteered to coach his daughter's basketball team. He sees a basketball game for the first time. When one team scores, he noticed that they immediately retreat back to their own basket. A basketball court is 94 feet long, and they give the first 60 feet away for free! He thought it was retarded. Here's how it turned out.

A Major League Baseball GM for a low-revenue team is sick and tired of losing to his better financed opponents. Realizing that he can't compete in a bidding war, he looks for odd players that may be underpriced. He hears of a pitcher named Chad Bradford, who is posting amazing numbers in AAA ball, but no team is willing to promote him to the Show. He's a submarine pitcher; he throws funny. The GM wonders...this guy gets people out, but no one's willing to let him do it on the big stage just because he throws funny? He thought that was retarded. Here's how that turned out. I recommend the book instead of the movie.

Now, follow the meta all you like, but unless you've got something special, what makes you think you'll get different and better results than an average player? Hey, to make Platinum in NA, you've got to get past 90% of the entire ranked player base! You think that's gonna happen doing what the rest of the player base does, or by doing something different?

I just recommend starting to look for common things that seem retarded. I can assure you the player base of League of Legends will provide plenty of material for you.

But if you let other people do the looking...do you really think they'll see anything?

i said that he didn't need to have any business knowledge, his fortune was made off of a technology that none of his competitors had, which gave him an absolute edge - it's like being able to buy stock at a 50% discount and then sell it at full value on the open market.

one of the last things i mentioned was that fred koch was a great businessman and chemist - my intention was to insinuate that failure was nearly impossible under that set of circumstances. he was in an almost constant legal battle with the enormous e&p monopolies of the time, he brought his technology to the ussr when he couldn't use it stateside, and he created the platform for an oil services/technology company in probably the best time in early american history to do so. he was booming while the stock market was crashing and his innovations in using lighter napthas to create more gasoline out of the same amount of crude oil made rock island oil into the empire that it is now.

if i'm being candid, i wasn't expecting to be asked for sources since people post complete bullshit here all the time, and my original post is clearly littered with my opinions and isn't intended to be an academic exercise..

i'll give you a list but you might have to go to the library or hit up amazon

sons of wichita - dan schulman (the book's alright but gives insight to the early generations of the koch family rather than brothers)

oil 101 - morgan downey (describes the oil industry from top to bottom in a digestbile and interesting way, totally recommend if you're even sligthly interested in learning about the industry - describes cracking as it relates to refining business)



you can easily google the history of koch industries too, as well as excerpts from the books.

Photo of the Finished Product

This recipe is from San Francisco's Smuggler's Cove, which is absolutely one of my favorite tiki bars.

The bar's creator released a fantastic book loaded with Smuggler's Cove recipes but also history of tiki, a breakdown of different rum classifications, and even how to decorate for a tiki bar. I highly recommend it.

Recipe:

• 0.75 oz fresh lime juice
  
• 0.25 oz fresh grapefruit juice
  
• 0.25 oz homemade cinnamon syrup
  
• 1 tsp homemade grenadine
  
• 0.5 oz John D. Taylor's Velvet Falernum
  
• 1.5 oz blended aged rum (I used El Dorado 12)
  
• 1.5 oz column still aged rum (I used Zacapa 23)
  
• 1 oz black blended overproof rum (I used Lemon Hart 151)
  
• 2 dashes Herbstura (1:1 mixture of Angostura bitters and Herbsaint)
  
  Combine all the ingredients in a shaker with ice and shake, open pour into Zombie glass or other tall drinkware. Garnish with mint. (The original recipe calls for a flash blend, open pour with gated finish.)
  
  Obviously, this is a very strong drink, so being able to make it at home is nice, even if a little prep-work is required! It packs a punch but it is extremely complex, flavorful, and not cloyingly sweet. If you have the patience, it's a worthwhile, serious tiki drink.

X-posted to r/tiki as well

It's been hot in northeast Georgia, hot and humid!! To me, that means Mai Tais!

I've been drinking quite a few lately, because I'm also putting together a side-by-side overview of four different orange liqueurs to be posted on r/cocktails soon. This is a fantastic way to experiment a bit.

I start with the Mai Tai recipe from Smugglers Cove and tweak just a little...

• 1 oz Doorly's 8-year old Barbados Rum
  
• 2/3 oz Denizen 3-year old Aged White Rum
  
• 1/3 oz Smith & Cross Navy Strength Rum
  
• 3/4 oz Lime Juice
  
• 1/2 oz Clement Creole Shrubb
  
• 1/4 oz homemade Mai Tai syrup
  
• 1/4 oz homemade Orgeat
  
  Combine in a shaker tin with 12oz crushed ice plus a couple large cubes and shake until the tin frosts up. Dump everything into a double Old Fashioned glass and garnish with a spent lime shell and a sprig of spanked mint.
  
  Notes on my Mai Tai:
  The book, Smugglers Cove, is simply brilliant in how it handles rum. I've been a whisky guy for many years, and just in the past 6 months or so have begun exploring rum. The Smugglers Cove book, and the subreddits, r/rum, and r/tiki have all been fantastic resources.
  
  As outlined in Smugglers Cove, the original rum Trader Vic had access to when he created the Mai Tai (J. Wray and Nephew, 17-year old Jamaican) is not available today. Fortunately, the tiki gods are generous and gave us Martin and Rebecca Cate, who go on to describe the history of the Mai Tai in fantastic detail. If you are a fan of rum, or tiki, or just general booze-lore, I cannot recommend the book Smuggler's Cove: Exotic Cocktails, Rum, and the Cult of Tiki highly enough.
  
  With that being said, the book describes mixing various rums to achieve a profile similar to Vic's original. I do not claim to have recreated the original with my mix of Doorly's, Denizen, and Smith & Cross, but based on some trial and error (is it really an error, when the result is still a damn good Mai Tai?!) I did find a flavor combination I absolutely love!
  
  My "tweak" is to use 1/2 oz of Clement Creole Shrubb in place of Pierre Ferrand Dry Curacao. Nothing at all wrong with the Ferrand, it's just that, to me, the extra little bit of spicy funk from the rhum agricole base adds a perfect note to a Mai Tai.
  
  The Mai Tai syrup and Orgeat are both recipes from Smugglers Cove as well. The syrup is a 2:1 Demerara with a bit of vanilla extract and a pinch of salt added. The Orgeat is pretty standard stuff, almonds, water, sugar, orange blossom water and rose water. Both are well worth making and keeping around in the refrigerator.
  
  ~Cheers!

The team I'm on is somewhat unique in our organization and we have been using a modified and always evolving Kanban method.

Our choice to try Kanban came after having read The Phoenix Project by Gene Kim. We really loved the iterative feedback that a system like Kanban can provide.

We started with yarn and sticky notes on a whiteboard until we felt comfortable with the process and then migrated to Kanbanflow. We do individual task time tracking in Toggl.

We had played with bigger solutions targeted for VAR/MSPs but found that they also wanted to be CRM solutions (and a lot of other cruft that we didn't need). Basically, we were wasting our time trying to learn tools instead of processes.

Will we be using these solutions six months from now? Who knows. We are able to shift pretty easily between tools and like to be able to pick what we need. We tend towards simple, useful SaaS offerings that know what they want to provide and do it really well.

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.

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.

Start With Why [Simon Sinek]

48 Laws of Power [Robert Greene] (33 Strategies of War, Art of Seduction)

The 50th Law [Curtis James Jackson]

Tipping Point:How Little Things Can Make a Difference and Outliers: The story of Succes [Malcolm Gladwell]

The Obstacle is the Way, Ego is the Enemy [Ryan Holiday] (stoicism)

[Tim Ferris] (actually haven't read any of his books, but seems to know a way to use social media, podcast, youtube)

Get an understanding to finance, economics, marketing, investing [Graham, Buffet], philosophy [Jordan Peterson]

I like to think us/you/business is about personal development, consciousness, observing recognizable patterns in human behavior and historical significance. It's an understanding of vast areas of subjects that connect and intertwine then returns back to the first book you’ve read (Start with Why) and learn what you've read past to present. Business is spectacular, so is golf.



To Add:

Irrationally Predictable:The Hidden Forces that Shape Our Decisions - [Dan Ariely] (marketing)

The Hard Things About Hard Things - [Ben Horowitz] (business management)

Black Privilege: Opportunity Comes to Those Who Create It - [Charlamagne Tha God] (motivation)

The Lean Startup: Use Continuous Innovation to Create Radically Successful Businesses - [Eric Ries]

Zero to One: Notes on Startups, How to Build the Future - [Peter Theil]

That sounds tricky. I think you're starting with the right place: visualizing workflow;

A suggestion is that you focus on building trust by addressing pain points. What pains does the team have with the current process and can you concretely improve those in the short run (as opposed to abstractly saying "if we adopt this whole enchilada that will get better, trust me").

Another thing to focus on is measuring some of the health indicators in Accelerate. Honestly, you might be doing awesome already and the problem to be solved is recognizing and celebrating it. Good luck!

Investing without prior knowledge of the industry is inherently risky. It is important that you are not placing "bets" on these companies, but rather you are speculating. Speculating requires research and in finance provides a premium for taking on extra risk. Gamblers take on risk without the potential for extra reward. I have a solid (but in no way am I an expert) knowledge of the energy industry, so here are my tips:

1. Avoid oil sands companies (COS, SU) like the plague. There are a large amount of oil sands companies located in Canada, but the production and refining is not profitable in the current market. I believe the break-even point for oil sands is approximately $50 per barrel. West Texas Intermediate (WTI) crude is currently floating around $35, with low expectations for the future. As well as this, producing synthetic crude is notoriously bad for the environment if you are concerned with socially responsible investing.
   
   
2. Invest $1,000 in a combination of PWT, IMO, HSE, CVE, ECA, and CNQ. Do your research and figure out what companies have competitive advantages in their operations and decide why you believe they will be successful in the future. Most of the above are integrated O&G companies, so you will need to understand the upstream, midstream, and downstream segments. I am confident that a majority of O&G companies can be bought for cheap in the current market and will provide growth in the long run.
   
   
3. To hedge the risk from your exposure to solely the oil industry, invest $1,000 in a diversified ETF. See this list for examples. Again, you will have to do your research here to figure out what you want to be exposed to and what kind of returns you want.
   
   I understand that you want to experiment with investing, but this strategy will give you the opportunity to learn about investing while reducing your exposure to industry risk. Your single picks may lose money, but as long as you learn where you went wrong you are provided a net benefit. As short-term to medium-term investing requires finance savvy, I would recommend always holding over a long-term.
   
   Also, if you are interested in learning about the oil industry, I would recommend reading Oil 101, The Prize, and The Frackers.
   
   Good luck!

It's kind of dumb but there are two different "CD"s.

The first level is CI, which is committing code and having something that builds it automatically and runs all the tests.

The next level is CD (Continuous Delivery), which is a process that takes your successful integration builds and pushes them out to some set of environments (e.g. UAT or staging or whatever). From there you might have some set of additional tests that run, maybe load tests or integration tests with live external systems.

The third level is CD (Continuous Deployment), which is a process that takes your successful delivery builds and automatically pushes them to production.

In a true continuous deployment pipeline there's no gating step where people sign off on UAT (this doesn't mean there's no people involved anywhere, for example code review pre-merge is fine). You write your tests, you merge your changes, and if everything passes the changes just show up in production.

The part of your process that makes it not "true CD" is the human sign off in UAT.

That being said, TRUE AUTOMATED CD IS NOT RIGHT FOR ALL SITUATIONS! There are many business reasons that you might not want to or be able to apply a true continuous deployment model.

IMO the best book on this stuff that's out right now is https://www.amazon.com/gp/product/1942788339

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

Cocktail Kingdom is located in NYC.

36 West 25th Street, Fifth Floor, New York, NY 10010

Go check it out, good stuff there.

Honestly, if he has his OWN bartending equipment, a really nice leather bar roll-up would be nice.

http://www.cocktailkingdom.com/all-barware/bags-case

Depends on your budget.

If he wears an apron at work...

http://butcherandbaker.com/

I love their aprons.

Books are always good for inspiration.

https://www.amazon.com/Smugglers-Cove-Exotic-Cocktails-Cult/dp/1607747324

This one came out recently and I couldn't recommend it more. The people who wrote it are probably the foremost tiki and rum experts in the world. It's the best cocktail book since Death and Co.

What makes you think they wouldn't have started selling it without regulations? if there was no need for licensing they could have literally walked into any liquor store or bar and said "Hey im George Clooney can you do a test run of some of my tequila" without ever needing to go through government.

Someone like Clooney is an outlier because he is rich and famous but there are tons of stories of people doing things they love and are good at, but are prevented from monetizing it because of regulations. Like that guy in LA making bread in his kitchen, he was fined thousands of dollars for selling bread because he didn't have a commercial kitchen and correct licenses. This despite the fact that he ran a tight ship and his customers loved him. IIRC he had to pay like $20k+ out of pocket, then a couple years later California legalized selling homemade food.

There is a popular green/sustainable farmer called Joel Salatin who wrote a book about how regulations are killing small farms and food businesses and how they make it too onerous for small operations and local food growers to serve people.

I love your last point BopCatan! It's awesome to see the confused looks and stutters from the ignorant people when they see a strong fit person tell them they're vegan.

As for my motivations I'd say I'm a bit of a mix of both. I was inspired to look into it because someone I have a lot of respect for decided to become vegan. In short, what I found was that a lot of the animal products we ingest are far from the simple collection of healthy nutrients and proteins that they were sold to me as. I had already mostly phased out red meat based on previous health risks I had researched, but my initial response was to switch to eating only locally produced meat where I could be confident in knowing where and how it was produced. Over time I kind of just stopped eating that all together too as I noticed how much better my body was feeling after vegan meals. I used to get stomach aches quite regularly or feel tired and sluggish after eating and those problems vanished almost instantly. Plus my girlfriend was a vegan before me anyways so I was learning to cook some awesome vegan meals to impress her anyways!

My ethical motivations sort of developed alongside my already growing veganism. A big part for me came from focusing on the damage mass production of animal products does to our planet. There's so many aspects to this and I don't want to write a short story on here but I'd say my introduction to these thoughts began with factory farming. I had a discussion with someone where they explained how these methods are often so stressful to the animals being slaughtered for consumption that huge amounts of meat and milk was being spoiled by the animal’s own stress hormones and that products that were still being pumped out of these factories were causing disease and poor health significantly more then ever before. This was a big deal to me, but the kicker was later reading an article about how researchers for some company were attempting to genetically modify the cows so they wouldn't have a stress hormone to release in the first place. This just seemed like such a ludicrous response to me. Rather then recognizing that hey, maybe what we're doing is pretty bad after all, we decide to mess with the genetic composition of our food even more? Really? And that says nothing for the ethics of putting animals in a situation where they feel so much terror that they are destroying their own bodies from the inside out.
(I can't remember the exact articles I read but just did a 5 second Google and here is one that talks about the stress response of animals).

There are many more environmental factors to my ethical “motivations”. Another big one for me is the massive amounts of C02 created from all the production and shipping we do. But ya, there are people way better qualified then me to talk about this stuff.

If you’re looking for a good articulation of ideas and facts I’m currently reading a really cool book called Eating Animals by Jonathan Safran Foer (the guy who wrote Everything is Illuminated) discussing his research into food production preceding the birth of his first child. I dunno if it’s the best book ever, and I haven’t even finished it, but I figure maybe it’s something people haven’t heard of rather then suggesting people go read Michael Polan or watch Earthlings etc. (not saying those aren’t worthwhile!).

Well, on the extreme side, "The Professional Chef" textbook I believe is the one used by the culinary institute of America. I picked one up off Amazon for $36 just for the hell of it. It's really interesting and reads more like an academic text than a cook book. It can be quite intense though.

A much more popular choice and a much easier read would be "The Food Lab" by Kenji Lopez-Alt who is a writer for serious eats. The book has plenty of recipes but does an unbelievably amazing job explaining the science and reasoning behind the choices that are made as well as various "experiments" that kenji does to answer cooking questions. It definitely teaches technique and really helps put you in the right "mindset" for cooking without a recipe.

Here are links to both.

https://www.amazon.com/Professional-Chef-Culinary-Institute-America/dp/0470421355

https://www.amazon.com/Food-Lab-Cooking-Through-Science/dp/0393081087

I'll give you two book tips:

1. Never split the difference by Chris Voss, an ex FBI hostage negotiator. This is about negotiation techniques that everybody can use. A better negotiator has more power. Negotiating is not about overpowering and bluff, it's about finding common ground and making a connection.
   
2. Simon Simek - Start with why. This book was for me really useful, but given your situation, your "why" may be very clear. Still it's a good book as your "why", your (underlying) motivation may not be entirely clear to yourself. Sometimes you do things without really knowing why. Don't expect this book to explain the whole complexity of your inner self - it doesn't, but well - if you have the time and energy, it might help.
   
   I don't know if you can order these books. Both are available as EPUB as well if you use a normal e-reader or laptop.

I havn't watched this doc yet, but if you're curious to read in depth into this topic, and it's truly fascinating. I can't recommend the book The Prize enough. It's a great read and you'll see how modern power was shaped well into the 20th century.

You are asking good questions. I appreciate your openness and I hope I can add something here. I hope we are not divided as it feels sometimes. Also, you might find it comforting that our country has survived division of similar if not greater magnitude before.

" why can’t you adults do the same "- I hope you will find that some of us can. Can you think of a marketing strategy for us? How many clicks/views would this headline get: "Nobody slams anybody- two dudes who disagree have an amicable conversation and agree to keep the dialog open despite disagreement" Are you familiar with the phrase "If it bleeds, it leads" ?

Also, I will note that nuanced argument takes more time and effort than the sort of shit in the two links below:

​

Here is an anti-Trump post relying on an emotional appeal. How much of the Republican party do you think this picture accurately represents? Does it matter what the opposition looks like?

https://www.reddit.com/r/PoliticalHumor/comments/ceca5l/a_gentle_reminder/

Here is an anti-liberal post based on a straw man argument. (IE- they are dunking on an imaginary liberal, they didn't find a person- let alone a majority of people- who espouse this view)

https://www.reddit.com/r/Conservative/comments/cbiydd/the_thought_process_of_the_left/

​

For more on the financial incentives involved in sensational headlines I like this book:

https://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285

It boils down to the fact that game studios, especially the ones that are owned by larger parent companies, are under pressure to hit deadlines. Game development is a business, and studios have financial goals to hit to justify investments in what they're doing. Most video games are sold on marketing and hype anyway, and final builds are usually delivered for distribution well in advance in release day. Generally teams expect to have day-1 patches to fix those bugs, but in many case then can't all be addressed day one. In those cases they triage the largest bugs, and fix smaller ones in later patches.

[Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made]
(https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234) is a pretty great read, and give some interesting insight into what it takes to get a game out the door.

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!

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.)

Here's some recommended reading:

• The Book - That's literally the name of the book. It's full of one-off chapters covering a variety of topics.
  
• Baseball Between the Numbers - This one is also a bunch of one-off type stuff
  
• Moneyball - Talks about how the 2002 Oakland A's capitalized on some offensive statistics that were being recorded but not heavily utilized to determine player values, and thus built a playoff team from undervalued hitters
  
• Big Data Baseball - Talks about the 2013 Pittsburgh Pirates and their use of big data strategies to find defensive value where other teams didn't (primarily in pitch framing, ground-ball pitching, defensive range, and shifting)
  
  The first two of those are heavily focused on the numbers and will probably teach you more about the whys and hows, while the second two are more about the narrative but still give you some insight into hard numbers.
  
  Also, I'd recommend just joining SABR. It's $60/year for most people, but if you're under 30 it drops down to $45/year. There are a lot of local chapters out there that have regular meetings. For example, the Twin Cities have the Halsey Hall chapter. There's a book club meeting on Saturday (to talk about Big Data Baseball), a hot stove breakfast in a few weeks (informal meeting to just hang out and talk baseball), a regular chapter meeting in April for people to actually present research, and the chapter occasionally has organized outings to minor league games.
  
  SABR also has a national conference and a specific national analytics conference, as well. Membership also includes a subscription to Baseball Research Journal, which comes out twice per year and contains a lot of really good stuff that members have been written both from a statistics and a history standpoint.

So a few off the top of my head:

1. The Professional Chef. Geared towards professional chefs but a great resource.
   
   
2. On Food and Cooking. A classic. Not really a 'cookbook' per se but rather a book that discusses history and food science.
   
   
3. The now out-of-print Williams and Sonoma Mastering Series. Specifically, their book on sauces - the others are solid but not quite as good. Those books were how I personally learned to cook. (still can find used)
   
   
4. The Flavor Bible. Obligatory. Eventually you grow out of it a bit, but it's still a great resource to have around.
   
   
5. Flour Water Salt Yeast. I just got this book recently this last Christmas, and I've been enjoying it quite a bit.

> Sure, that's called documentation.

Which could serve the purpose, yes. However, with someone SSHing into the box and possibly making changes what is the likelihood the documentation will be kept up-to-date?

I've migrated multiple clients who had servers they had no idea how to recover should a disaster strike and nearly all of them had "documentation". Reverse engineering a setup is a painful process... especially when the original implementors, like you, have left long ago.

Now, truthfully, the same can be said for scripts\source code... but at least we can test the scripts and vet them more quickly then manual documentation.

> I automate things when they have to be done repeatedly.

Sure, except you are making some big assumptions about what is potentially in need of being repeated (and likely making those assumptions with your companies money and likely without their input on the risks) . Especially if that repetition comes after you leave. The loss of institutional knowledge can seriously damage an organization. In the cloud, which is largely what we are talking about these days, you must work from the assumption that your instance can poof and go away at any moment.

I already indicated that, at times, a simple snapshot or backup of the machine can be sufficient for the companies needs. I still feel that source code is better but SOME way to recover is critical and some way to replicate to another environment can likewise be valuable for an organization to innovate (by being able to test things in a non-production, safe place). What is your MTTR? If it is not minutes your are failing your employer.

> It'll all be out of date the next time I need it.

Then you're doing it wrong. And that's why so much of what you are saying is concerning me. Look, if your company is making an informed decision based on how you are working... more power to you.
However, more often then not they are looking to you as the expert and, frankly, you clearly not. You are taking risks that you won't have to pay for, they will. [And that's generally when they call someone like me. A real expert.]

> work in a field where things can be down for 3-4 hours in an emergency.

Wow... I work with companies where minutes of outage can be millions upon millions of dollars. And I have yet to find smaller clients who don't want to be in that space. Why let the technology be their blocker when it doesn't have to be? I'm frankly surprised that even smaller clients would tolerate outages of that length more than once. It's sad they allow themselves to be put into that position when there is no valid reason for it, it's just laziness. Furthermore, doing the "infrastructure as code" way is actually faster and produces much higher quality in the long run anyway.

It's like when some organization gets hacked and you find out their security was a complete joke while millions of passwords are leaked. That happens because people working there hold themselves to a very low standard and the company either doesn't care, is specifically choosing to save the money despite the risks, or much more often just unaware their people are making those choices on their behalf.

> Yet it's the stupid rules like "SSH in production is an anti-pattern" that young people latch onto and treat like gospel.

I'm not one of those "young people" you might be referring to. I do agree that OPs article is in-artfully presented... but I agree (and practice) wholeheartedly with the philosophy and adhering to it. My 26 years of experience building and delivering enterprise software have proven to me that so-called DevOps is not only the right way... it is the best way for high performing teams and high performing companies. And in case you are unaware, high performing teams are correlated to high performing companies statistically.

https://www.youtube.com/watch?v=gsjCWrCUjNg

https://smile.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

This is quite interesting so I will go ahead and put MAXIMUM EFFORT into it

chapter 1 - ikuto's talent would have gone unnoticed if chiyuki (someone born into the fashion industry) hadn't gone out of her way to hunt him down and then had a moment of self-realization "impossible probably".

chapter 2 - chiyuki's dad (an insider) happens to get a call from a former co-worker and decided to back ikuto who stood up to him for chiyuki's sake.

I have had me mentor pull some strings for me too when I used to work in research and academia...one phone call and I was having lunch with a top government official

chapter 4 - well he is a raw talent born in unfavorable circumstances which isn't unheard of in real life

chapter 5 - not unheard of...people in influential positions use opportunities to further kids all the time

chapter 6 - again, not unheard of...in fact, it is quite common in event management for things to fall in chaos when someone isn't able to come (either travel/overwork/sick)

chapter 7 & 8 - creative work is hard to....predict/control. There are moments when you shut down wondering how you managed to do it before and others where everything falls into it's place like a jigsaw

chapter 9 - not much of a cliffhanger here

chapter 10 - not unheard of...people managing the event and those managing the inventory have an instance of miscommunication. All events are susceptible to failure due to a lot moving parts

chapter 11, 12 - resolutions, no cliffhanger

chapter 13, 14 - MC mentions earlier (chapter 1) that he wanted to give up his dream because of his unfavorable circumstances...we were going to find out the full extend of it sooner or later

chapter 15 - I liked this one a lot...we have to wait a week before we find out the result of ikuto's self-reflection...chiyuki has her moment of self-reflection back in chapter 1.

Up until now, it's been been other people pushing him into it and he is responding to situations. Now he needs to figure out why he wants to be fashion designer. To be one is to design clothes that appeal to the masses, It isn't enough to want to make clothes (for his sisters/mom). He has the talent but it isn't good enough he needs to be obsessed about it to keep at it long enough.

Remember, chiyuki had other agencies willing to take her on or she could have compromised and moved into another profession where she wouldn't denied for being short. She chose her namesake, Mille Neige.

chapter 16 - resolutions, no cliffhanger

chapter 17 - cliffhanger...first one that is not set up well enough but I'd wait for the next chapter to pass judgement on it.

I have no idea about the fashion industry but I have heard people quitting companies in the middle or right before key events in the video game industry for health or creative differences.

>it so often just gets me rolling my eyes and sighing and this little last page dramatic twist cliff-hanger perfectly embodies why

I think you have been quite harsh in your assessment. I found none of the cliffhangers hard to believe/outlandish.

It's not like the MC fell on top of a female while she was in a public bath (every ecchi manga ever) or ran into his girlfriend's (and step-sister) step-sister and saw her underwear.

>At every turn it feels like the author is trying to use every little trick they can find to make things just a little more intense, more dramatic, as dramatic as they possibly can and it just ends up feeling overplayed.

I disagree...I could relate to it esp. working in a high stress environment. I mean sure the manga is structured in a fashion that maximises the impact but all of those things are quite common in industries like fashion, event management, animation, video games, research and academia which subsists on creative work and crunch (over working to meat deadlines that are hard to predict/pin down) is the norm.

If you ever happen to start things from scratch or attempt a startup, you will realize that more often than not find that one little thing or other can lead to near total collapse...it is dramatic by it's nature

First, read our Wiki. It is very thorough and answers a lot of these common questions such as

day to day? The Practice of System and Network Administration
And the topical reference books listed below.

Books to help in shaping a sysadmin? The above &:
The Phoenix Project
Time Management for System Administrators


Topical Books I see mentioned often and have been very helpful to me:
Powershell in a month of lunches
Learn Python the hard way
Unix and Linux System Administration Handbook
Windows Server 2016: Inside Out

Group Policy
AbsoluteBSD
FreeBSD mastery:ZFS
CCNA
RHCSA/RHCE
Pro Puppet
SSH Mastery

On my docket:
FreeBSD Mastery: Advanced ZFS

Michael W. Lucas and Thomas Limoncelli are very good sysadmin writers, you can't go wrong with a topic they have chosen to write about.

Most of the *nix stuff assumes a baseline knowledge of how to use a unix-based system. I learned as I went but did pick up an old copy of Unix Visual Quickstart Guide not too long ago at a used books sale, which seems like a good starting place for someone overwhelmed with sitting at a terminal and being productive.
I notice I don't have any Virtualization books, perhaps someone else can fill in good books. Most of my knowledge regarding virtualization and network storage has been a mix of official docs, video training, and poking at it. Seems innate but it isn't.

Nope. Nope. Nope.

first things first, the article says they could be extinct "within a decade," and it was written in 2003...so there's that.

now, let me elaborate. The type of banana grown in most of central america is called a "cavendish," it is vulnerable to panama disease race 4, which is not present in central america (but it is pretty much everywhere else). when people say that the cavendish will be going extinct, its because of the inevitability of that strain reaching central america, which it surely will at some point.

now let me discuss that. Bananas are very big business. i believe its somewhere along the lines of 90%+ of American households have bought bananas in the past month. that's huge. Now, do you think that the big fruit companies will allow them to go extinct? that is their cash cow, their core business. they learned a lot from the Big Mikes. For example, in the Philippines, i heard that when panama disease was found on a farm, they burned the whole thing to the ground and didn't use it again for like 30 years. Also, everything that went into the farms and came out of the farms was disinfected...people, vehicles, tools, everything. With the Big Mikes, none of this was done and that why it spread so quickly.

black sigatoka is different, and definitely an issue, but not a huge one and is controllable on farm level to a very effective extent (as far as i know).

To put it in perspective, everyone i know that had anything to do with bananas in central america was never worried about Panama Disease, or sigatoka, or pests. they were more worried about the weather or volcano eruptions or some issue with logistics. believe me, a hurricane will have a much greater impact on a farm than some sigatoka.

Now, if something does happen, and the cavendish is in danger, there are literally thousands of different types of bananas. They would be a little more expensive, as the infrastructure for shipping bananas is based around the cavendish, but i'm sure they would get to you. Also, there is a lab (i forget where or who its owned by) that is dedicated to cultivating new bananas. They have had some success, but i don't believe anything commercially viable...yet.

so relax everyone, your cornflakes will have plenty of bananas for a long time.

source: i work for Chiquita.

TL;DR: Low level Chiquita employee explains why this article isn't entirely accurate.

EDIT: a good read

If you really want to learn to cook i would suggest getting the text book than many professional chefs use while in school, something like this:
The Professional Chef https://www.amazon.com/dp/0470421355

You dont have to read it cover to cover but you should use it ad a reference to learn the fundamentals and establish a basic set of skills that you can use as you continue to learn and try new things. Like many endeavors you can save a lot of time by learning the tricks of the trade in the beginning.

Also like others said youtube is an awesome way to learn, also check out Americas Test Kitchen on PBS.

This is actually the central premise of the book, Trust Me I'm Lying:

https://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285

Essentially, now that most media is online, and advertising sales are driven by clicks, clicks become the all important goal of most articles. And this is ushering in a new era of yellow journalism.

What drives clicks are anger / outrage/ fear / hate/ humor / sex - things that produce 'emotional valences.'

So take two headlines examples.

1. "Trumps election due to democrats's failure address the economic concerns of middle america, research shows."
   
2. "10 reasons why debate is pointless, and flyover state conservatards need to be put in re-education camps."
   
   Article 1 could be a wonderfully written, deeply researched article with a nuanced world view and actionable advice for winning in 2020. Yet, its not an exciting headline, and certainly does not spike a readers emotions. It gets 12,000 clicks.
   
   Article 2 could be raging drivel; an emotional , opinion based listicle with 250 words and 10 memes stolen from Reddit. But that headline is pure click gold. Those who are angry/hateful about trumps win will click, while trump supporters angry/afraid about the prospect of being put in political re-education camp will also click. Further, both sides will share this article with their 'sides' of the aisle online. Result, 1.2 million clicks.
   
   While article 1 is much better quality, article 2 is far more profitable for attracting advertising. As such, writers and editors will pursue more 'stories' like article 2.

Nice! I have added both to my reading list! The Prize: The Epic Quest for Oil, Money & Power sounds really interesting, I have been looking for an older book on the Oil Industry... those greedy bastards always make for a good read! I have found it hard to find books on Oil (or many renewables for that matter) that don't have a little slant.

[Children of the Sun: A History of Humanity's Unappeasable Appetite For Energy ] (https://www.amazon.com/dp/0393931536/ref=cm_sw_r_cp_apa_i_R02xCbQ1V4B98) looks like a really good in-depth read as well. I think the title of the book sums up an uncomfortable truth about humans in general. I also find that books that take a more general overview of energy have less of that "rah rah" in one direction or the other.

I linked them so others could find them easily!

A cast-iron skillet. Soon, your awesome searing skills will be no match for your puny kitchen fan. Just make sure you look into how to care properly for the thing.

As for cookbooks, like other people in the thread mentioned, Joy of Cooking and Mark Bittman's How to Cook Everything are great tomes of quality recipes. I would also recommend something along the lines of a culinary school textbook. I'm a big fan of The Professional Chef. This cookbook focuses a lot on technique and theory, but it's very thorough and still has plenty of recipes and delicious looking pictures.

>If you believe it's possible to allow wealth to concentrate into the hands of a very small minority

This happens under government. Government props up monopolies and creates barriers to entry into the market, hampering competition.

Corporations love regulations, because it helps them. Small businesses don't have armies of lawyers to sift through the tax code for them.

Here is a good source:

http://www.amazon.com/Everything-Want-To-Do-Illegal/dp/0963810952/ref=sr_1_1?ie=UTF8&qid=1380744203&sr=8-1&keywords=why+everything+i+want+to+do+is+illegal

I can provide alternatives if you'd like. Name an area and let's see how regulations could effect competition.

> Should we start learning how to build for Android, iOS, or some cross-platform tool? What are trade offs for each?

For instance https://ionicframework.com/

But honestly, as long as you don't need to develop native, as /u/Xen0_n mentioned, I'd go with a progressive web app. You write it once and it runs in all modern browsers. You also have access to e.g. GPS, can send push notifications, etc. But make sure, a PWA provides all the technical features you need! (Proof of Concept! -> I need to decide on the tech stack by the end of this month)

It's also important to consider your team's abilities. If everyone is a python developer, don't use c#. If everyone knows angular, React is probably the wrong decision. If there's not enough knowledge and experience present in the team - the people of a team can usually give quite good feedback about technologies (complexity, learning curve, if it's fun to work with it)

​

>What are common components of an app's architecture that we will likely have to think about? I know we'll need a front end and a back end with a database, but I'm guessing we'll need to consider things like communications with the server storing the database? -How do apps link these components together/let them talk to each other?

Usually Multitier architecture. E.g. the front end communicates with a REST-api, rest API with a business layer, business layer with a persistency layer. What you use (programming language and back end) will determine how the communication will work. With Java and a relational database it will be most likely be JDBC with the given driver of the DBMS.

But also think about the cloud - this has some impact on the software architecture (aka could readiness).

​

>What are common mistakes when making early design decisions that cost you down the line in efficiency and maintainability?

From my experience:

• In general violating basic object oriented design principles (SOLID, cohesion, coupling,...), e.g. passing around Objects from the OR-Mapper directly to the client, instead of designing API's. Or bi directional dependencies of packages.
  
• not applying good software development and delivery practices (software delivery pipeline, high test coverage, high quality tests, code reviews, release and deploy regularly, decoupled architecture..). You should never be afraid to change your software.
  
  ​
  
  > What should our development process look like? Simultaneous front end and back end development? Back end before front end?
  
  Don't split the team into front end and back end if you can avoid it. Only if the team is getting too large to be effective, a split should be considered - having two teams will usually end up in finger pointing. Better is to code by feature. And split up a feature into smaller tasks (work in small batches), think about MVP: A small batch which already generates value to the customer and also generates feedback. It doesn't need to be feedback from production, but can be from a customer.
  
  How you write and deliver software - from requirements engineering, UX testing, actual coding and whatnot to deployment into production - is a really large subject. And there's no 'one size fits all'-approach - every environment is different. I'm a disciple of agile software development: The Manifesto for Agile Software Development and Continuous Delivery (and: Accelerate).
  
  Important is, that you guys always improve the process (as in continuous improvement). Not only within the team, but also and especially with the customer.
  
  ​
  
  Another thing: Don't forget security. The outcome of a security audit can be painfully expensive.

This isn't a short and sweet answer by any means, but if you're interested in understanding what it is about modern-day journalism that makes it so intrinsically difficult for honest journalism to flourish, I highly suggest you read Trust Me, I'm Lying by Ryan Holiday. I jut got done reading it a few weeks ago and found it fascinating.

>I feel as though I'm going to be "messing up" alot with clients.

yes. A lot. It's normal

BA in kin would be a waste of time unless you plan on doing physical therapy or want to work in more clinical settings.

I'd suggest reading and messing up with clients; it's the only way you'll learn. Two books that offer fairly different, but great, base beliefs as well as programming are

Starting Strength by Mark Rippetoe

New Functional Training for Sports 2nd Edition by Mike Boyle

as well as Start with Why

Dude, that's fantastic news. This comment immediately got me subscribed for updates.

Some other source recommendations off the top of my head...

Tiki drinks:

• Just about anything Jeff Berry has put together for tiki drinks. I would argue that Mr. Berry is as responsible for the modern resurgence of tiki cocktails (and their re-elevation to being carefully crafted, quality drinks) as anyone in the industry.
  
• Martin Cate's Smuggler's Cove
  
  General cocktails:
  
  
• Dave Wondrich's Punch and Imbibe - note that you may have to do a bit of reading to arrive at the recipes, as these (and several of the other books I'm about to mention) spend a good bit of time on history and/or technique in addition to "just" containing recipes.
  
• Dale Degroff's Craft of the Cocktail
  
• Jeffrey Morgenthaler's The Bar Book
  
• Gary Regan's The Joy of Mixology
  
• Kevin Liu's Craft Cocktails at Home
  
• The Dead Rabbit Drinks Manual
  
• Dave Arnold's Liquid Intelligence
  
• Vintage Spirits and Forgotten Cocktails
  
  
  ...that's... not a bad list to get started. Good luck! I'll be interested to follow along with development.

You rang?

I haven't read the book, but I've heard a couple interviews with the author through my various foodie podcasts. He seems cool, and he made bananas seem downright fascinating the entire time he was speaking.

Edit: I have read and would heartily recommend The Omnivore's Dilemma by Michael Pollan if you're even a little interested in the genetic, behavioral, and political! manipulation of our food. Corn, in particular, as it's the backbone of the American food industry, but he covers a lot of ground. It's really eye-opening. Do recommend. (And any half-decent American library will have it, so awesome and free.)

Hello,

From my experience, the tool selected for a project will always become the wrong choice after a certain period of time. It is never obvious which tool is the best at the beginning of a project. An experimented team will more likely make reasonable choices but they should always keep in mind that the tool they use will be replaced at some points or modified. That's why architecture and good coding practice are the cornerstones of a project able to withstand evolution.

I had to work, one day, on the transition from SQL to MongoDB. There is no magic, all the code calling the SQL data source had to be rewritten. It is a costly process but the final cost of the operation mainly depends on how well the calls to the database are isolated from the rest of the software.

Sadly, I don't have any tools for handling this specific case. But I can recommend those books :

• For your team it could be interesting to read Clean Code : Some of the approaches of this book could be contested, but globally the essence of what it teaches is useful for designing good evolving software
  
• For a manager I recommend Project Phoenix : It is a fiction about a company struggling to manage its IT and how the new CTO tries to overcome those issues. It is a good fable with a lot of lesson for IT management.

I probably have around 250-300. I used to have about twice that, but I traded a HUGE amount in to a used bookstore.

Oops, genres...Mostly scifi/fantasy for fun reading, though non-fiction is gaining, with things like Banana and Bryson's Short History of Nearly Everything.

>But if these technical solutions mattered so much, wouldn’t we see that reflected in the research?

We actually do.

The Role of Continuous Delivery in IT and Organizational Performance .Or Accelerate: The Science of Lean Software and DevOps for those who want more digestible form than research paper.

tl;dr : Technical practices like TDD, refactoring, Continuous Integration, Trunk-based development and others do have strong statistical correlation with organizational performance. And while correlation is not proof of causation, it is true that successful business and strong technical practices are found to go together.

The problems with research quoted in the articles is that it either only uses open-source code or has too limited of a scope to be useful in real-world scenarios.

The Prize: The Epic Quest for Oil, Money & Power

"[...] The Prize, winner of the 1992 Pulitzer Prize for nonfiction, is a comprehensive history of one of the commodities that powers the world--oil. Founded in the 19th century, the oil industry began producing kerosene for lamps and progressed to gasoline. Huge personal fortunes arose from it, and whole nations sprung out of the power politics of the oil wells. Yergin's fascinating account sweeps from early robber barons like John D. Rockefeller, to the oil crisis of the 1970s, through to the Gulf War."

Start with Soccernomics.

Lots of statistics in there, but it's very interesting.

Btw I'm using amazon links for easiness and because it's easy to read reviews of the books there, but i'm sure if you shop around you can maybe purchase them for less.

When you consider that they were forced by their publisher to make DA2 in only 16 freaking months. It is amazing to me that DA2 was even a playable video game, let alone anything resembling a good video game.

Then on top of that, DA:I was created in just 3 years, and Bioware was forced to use Frostbite, even though it had none of the tooling required to make an RPG. Sure if DA:I were going to be an FPS Frostbite would have been cool, but for the entire first year of development Frostbite was basically an unusable mess to everybody but the environment artists and level designers, and even then their work was just an educated guess because the level designers couldn't even playtest their levels, they jsut had to make levels that would probably work given knowlege about the broad strokes about how the game was supposed to wind up.

On top of all that, they were forced to scrap a ton of stuff in DA:I because it was mandeated that the game come out on PS3 and XB360, even though those platforms only wound up consisting of 10% of DA:I's sales.

They didn't even have Iron Bull implemented in the game until 8 months before ship. All of the play testing up until that point was without a fufll party, because the party system had to be developed in Frostbite specifically for that game.

"The biggest differentiator between a studio that creates a really high-quality game and a studio that doesn't isn't the quality of the team" said one person who worked on Destiny. "It's their dev tools. If you can take fifty shots on goal, and you're a pretty shitty hocky player, and I can take only three shots on goal and I'm Wayne Fucking Gretzky, You're probable going to do better. That's what tools are. It's how fast you can iterate, how stable are they, how robust are they, how easy it is as a nontechnical artist to move a thing."

Once again, it is incredible that DA:I resembles anything close to a decent game given the tools and timeline they were made to work with.

Reading Blood, Sweat and Pixels made me want to rip EA's eyes out.

If anyone's interested in learning more about the history of banana, I'd highly recommend this book. The author does a great job keeping you interested, such a fun read.

I'm currently reading through a book called Soccernomics: Why England Loses, Why Spain, Germany, and Brazil Win, and Why the US, Japan, Australia, Turkey-and Even Iraq-Are Destined to Become the Kings of the World's Most Popular Sport and while I'm not yet halfway through reading it, its brought up some interesting statistics and theories that I didn't know before. Good points regarding sales of players, the most overpriced and underpriced positions, nations to buy from, etc. Its a really good Moneyball style book that I'd love to hear someone else's opinion of who has made it through all of it.

As were Bush, Reagan, and numerous other high ranking US officials, both military and civilian. There have long been close links between Riyadh and DC. For good reason.

The House of Saud, while now a convenient boogeyman for those with no sense of even recent history, has provided not just oil for many decades when there were inadequate supplies in North America (and Europe), but more importantly has been a key ally in the gulf, a place where instability is the natural state, and where Wahhabism especially would rapidly fill a power vacuum.

Is Saudi Arabia an ideal ally? No. We have many differences with them. But they are far better than the alternative. Through taking donations from the Saudis, Clinton was shoring up an important relationship while furthering the impact of her family foundation.

So you can criticize Clinton's relationship with the House of Saud, but see how quickly Trump cozies up to them.

I guess in summary, two things. One, these things aren't black and white, as cute as it may be. And second, keep your friends close and your enemies closer.

For more detail you can read the following:

https://www.amazon.com/Inside-Kingdom-Modernists-Terrorists-Struggle/dp/0143118277

https://www.amazon.ca/Prize-Epic-Quest-Money-Power/dp/1439110123

\> "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.

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.

​

​

​

It's really what works for you, this is the fundamental point of Agile which often gets lost, so if it's working for you that's perfect.

For our teams LEAN makes far more sense. As an example, Kanban replaces velocity with constraints. It makes it immediately obvious which parts of the process are bottlenecks.

Our priorities are set by the business on an available slot basis. We might be able to simultaneously work on three features. If three features are in flight there's zero capacity. The business can pause or abandon a feature, but they have to agree this by quorum (or dictatorially, hierarchy still exists :) ). Once a feature is complete a slot is available and the business can vote on what feature they want next.

So a feature takes as long as a feature takes. We still estimate, but there's no arbitrary sprint boundary to estimate around. We still subdivide tasks as an aid to estimation but again, not to fit in a sprint boundary.

We do stand ups (standing optional) in the morning, still meet as a team, but there's no need for a retrospective. If we are constrained by unanticipated volumes of support, or the task requires input from the business, the task sits in that column so we can see each day that support needs addressing or that someone needs chasing.

There's no formal backlog, the business set their priorities. This doesn't mean the team lead can't meet with the business, discuss future requirements and liaise with the team for informal estimates, complexities, etc. It sounds kind of chaotic but it works across many teams, although interestingly we still use scrum for the sort of transformational, multiyear multi team coordination.

If you're interested in taking a look at this, even if it's just to compare and contrast, take a look at this book. It covers pretty much all the above and a bunch of dev oppsy stuff in novel form. It's not dumbed down, and it is number 1 in its category.

I recommend reading The New Becoming a Vegetarian and Eating Animals. The first one will get you up to speed on how to get what your body needs without meat, and the second one will help you learn how to talk about it when your family and friends give you shit. Good luck and congratulations!

A book on novel writing.

Anything be Jared Diamond.

The Prize.

If he likes Mac, a subscription to MacWorld.

It's like I'm listing off everything my husband likes. :-P

Jefferson owned slaves. "Living wage" is not a concept that existed in 1776.

>the ability of people to provide for themselves

This ability does not include the right to employment at a wage that you deem acceptable. Given Jefferson's agrarian predilections, it was about the ability to grow your own food and sell it to make a living (thanks to the government, this has become very difficult). It was not about the ability to work less than x hours per week and still earn a living that meets your standards.

>If a government or other institution of men works against all people securing those things then it is a bad government or other institution of men and should be dissolved.

I agree. And threatening my employer's livelihood if he does not pay me an above-market wage is an oppression that works against his safety and happiness. I don't need the government to step in and decide how much my labor may or may not be worth.

>More likely that people in the 3rd world would take offense to the suggestion that they don't need electricity or clean water even though standard of living and life expectancy totally rise with increased access to either.

Have you ever met or talked with anyone from the third world? I have, and some are highly stressed by modern American life even though they have all those things. You're projecting your values onto them.

Not to mention that nobody arguing for a living wage is talking about having just enough money for clean water and electricity. Those are infrastructure issues and have very little to do with affordable living.

If you can find a copy of "The Professional Chef", snatch it up! It's the textbook used by the Culinary Institute of America. It has a ton of recipes, but also explains the different methods of cooking in detail. It's broken down into chapters like dairy, seafood, meat, grains and legumes, etc. I found an older edition at a garage sale for $1. It's a great resource to have. The only thing is that recipes are sometimes made for large-scale batches, so you'd have to do a little math to break it down into a reasonable amount. Nobody needs 40 poached eggs in their home at a time.

I have this one and this one. I like the first better, it's the one I used in my culinary school. The second is the one I got at the garage sale.

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.

I wanted to cook but was unable to take time off to attend a school. I'd been enraged with a crap meal in an expensive countryside resto at a dinner for someone, so the next day I went up the High Street and found THIS.

I wasn't smart on cooking but I realized as I think you do that learning technique rather than reciting recipes is the way to a happier kitchen future.

After that, I eventually got an edition of THIS. It helped expand on, but not replace, the lessons from Cordon Bleu.

I went through those before this day of Internet videos and information sharing occurred; you are a beneficiary of more modern times being able to search for a solution to your problems.

I wanted to ask a question about your relationship, but hesitate. I mean, (blushing) how much stock do you put into your ability to please your husband with cooking? I only offer that as a point of consideration as a long-time married man. Restaurant-quality food at home won't make or break a marriage (although horrendous food at home can contribute to a break-up); other aspects of a marriage more than compensate for the quality of home-cooked food. Take it from a long-time married person. An offer of a PM stands, and best wishes in your journey to moving your already-good home cooking to a higher standard.

the book eating animals by Jonathan Safran Foer is a great source for information about vegetarianism being a better solution for the planet.

it has an extensive bibliography of credible sources, and is an entertaining read (he also wrote everything is illuminated and extremely loud and incredibly close).

i find having some books as sources in research papers feels a little more substantial than all internet articles!

Edit: Since this is getting heat here's an excerpt from a book covering research done on this:

>Trunk Based Development

>Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance. Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had "code freeze" or stabilization periods. It's worth re-emphasizing that these results are independent of team size, organization size, or industry.

>Even after finding that trunk-based development practices contribute to better software delivery performances some developers who are used to the "GitHub Flow" workflow remain skeptical. This workflow relies heavily on developing with branches and only periodically merging to trunk. We have heard, for example, that branching strategies are effective if development teams don't maintain branches for too long - and we agree that working on short lived branches that are merged into trunk at least daily is consistent with commonly accepted continuous integration practices.

>We conducted additional research and found that teams using branches that live a short amount of time (integration times less than a day) combined with short merging and integration periods (less than a day) do better in terms of software delivery performance than teams using longer-lived branches. Anecdotally, and based on our own experience, we hypothesize that this is because having multiple long-lived branches discourages both refactoring and intrateam communication. We should not, however, that Github Flow is suitable for open source projects whose contributors are not working on a project full time. In that situation, it makes sense for branches that part-time contributors are working on to live for longer periods of time without being merged.

The book if you want to check their methodology / biases

Get 3-4 tools;

A Japanese-style jigger or a 50ml graduated cylinder

Ice. (And learn how it is made properly)

A cocktail shaker.

A strainer comes in handy too.



The cheapest way to practice; mix whatever booze you have on hand that is around 80 proof with some form of sugar, (honey, 1:1 sugar-to-water, 2:1 sugar-to-water, agave, Demerara sugar, etc...) and some form of citrus (fresh lime/ lemon juice). Just play around with the ratios of each (booze, citrus, sugar) till you learn how each affects one another.

For beginning bartending, I recommend familiarizing yourself with how alcohol is synthesized, the different distillation processes, and the types of booze from around the world.

From there, look on YouTube.

u/CocktailChem has a nice playlist for beginners called Basic Cocktails

Here is a couple of other playlists for you

The Educated Barfly YT

Steve the Bartender 365 days playlist

How To Drink

United States Bartenders Guild (USBG) seminars


Additionally, look for some books;

Cocktail codex(here)

Savoy Cocktail book (here)

Liquid Intelligence (here)

Smuggler’s cove (here)

Tiki (here)

The Aviary Cocktail Book (here)

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.

The other two answers are excellent. I would recommend that ANYONE interested in questions like this should read Soccernomics.

It answers A LOT of questions like this. Can't recommend it highly enough.

> Hygo Inc., a company focused on search-engine optimization and creating viral social media marketing, according to its website. Zhang's personal logo appears throughout the video.

AKA Media Manipulation; It's incredibly easy to sway blogs & other internet outlets nowadays without them even knowing it. I highly recommend Ryan Holiday's "Trust Me I'm Lying" if you're interested in reading on it further.

hey I read that! Matt Simmons ended up being dead wrong about peak oil, but otherwise I enjoyed the book. But The Prize by Daniel Yergin is the king of oil books - it is brilliant.

http://www.amazon.com/The-Prize-Quest-Money-Power/dp/1439110123/ref=pd_bxgy_14_img_2?ie=UTF8&refRID=04AERX02B4996WQXBJA0****

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).

Manufacturing Consent was good for it's time. Politically I consider it Chomskey's best and most important work.

The modern version is "Trust me, I'm Lying" by Ryan Holiday.

https://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285/ref=sr_1_1?ie=UTF8&qid=1491383790&sr=8-1&keywords=trust+me+I%27m+lying

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:

• Software Engineering Daily
  
• Future of Coding
  
• The Accidental Engineer
  
  Some good books:
  
  
• The Phoenix Project
  
• The DevOps Handbook
  
• Release It
  
  You should also check out hillelogram and his talks/podcasts/writing on TLA+ if you're not familiar.
  
  Do you have any good recommendations?

For social media you should check out different company blogs. Those are really helpful. I like the Buffer and Hootsuite blogs a lot.

But books are way better than online websites

For marketing you should read Traction by Gabriel Weinberg

Ryan Holiday's Growth Hacker Marketing and Trust Me, I'm Lying are insanely informative and fun to read.

You should read Trust me I’m Lying by Ryan Holiday. It brilliantly digs into the media ecosystem and explains exactly why you are right.

https://www.amazon.ca/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285/ref=asc_df_1591846285_nodl/?tag=googlemobshop-20&linkCode=df0&hvadid=292905515425&hvpos=1o2&hvnetw=g&hvrand=2803731859655008491&hvpone=&hvptwo=&hvqmt=&hvdev=m&hvdvcmdl=&hvlocint=&hvlocphy=9061024&hvtargid=pla-406163954633&psc=1

Spoiler: media went through this in the early 1900s when newspapers were sold individually. Subscriptions to papers is what Bred modern journalism as a virtuous pursuit like we understand it.

You are correct. Unless its an obvious generational talent (even those don't go in the top 3 - see Randy Moss), the players who end up being the best picks in the draft are usually the 2nd, 3rd, and 4th picks at their position. There is an excellent book called Scorecasting that delves into this subject. http://www.amazon.com/Scorecasting-Hidden-Influences-Behind-Sports/dp/0307591808

If you want to ensure it, take a note from the book Trust me, I'm lying [1] and use the new news cycle to your advantage. News trickles up, so share the "story", such as it is, with your favorite small time blog. That blogs desire for clicks on a big bit of click bate can result in more news channels picking it up as it appears to be an interesting story.

[1] Trust Me, I'm Lying: Confessions of a Media Manipulator https://www.amazon.com/dp/1591846285/ref=cm_sw_r_cp_api_obtUBbSH5NWBX

Thanks. If you liked that story, you'll love the book - it's essentially 10 stories like that, about 10 different games.

Also, assuming based on your username that you're also both a Nets and a Jets fan, I share your misery.

This is a great read as well. Highly recommend. A good insight into devops.

https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509/ref=asap_bc?ie=UTF8

I have definitely done this with great results. Just make sure you target the right blogs, be VERY personable and SHORT in your email... have one or two lines that makes you better/interesting to try and hook them. These two lines or so should be the only copy/paste you do on every email.

• If they sense any copy/paste format, you will be in their trash.
  
• Be very short, if you can't hook them on your greatest feature/differentiator, a full paragraph/story won't do it or be read.
  
  Seriously consider reading [this book: Trust me, I'm lying to you] (http://www.amazon.com/dp/1591846285).
  
  It will teach you how blog posts go "up the chain" of media broadcasting, what it takes to set that off, how to find which blogs the high traffic sites pull articles from, and overall is an interesting read for marketing. You may be able to find the info for free, he is a blogger/writer... so trying Googling: Ryan Holiday up the chain
  
  Again... seriously get this info. I read it in a few hours or day or so.

As I said below, this isn't really a story - It's cotton candy web content. I'm using a press release because It's a formal medium to get someone to share my pictures. In the Book "trust me, I'm Lying: confessions of a media manipulator" he talks about how most people who run blogs, or websites always need fresh content and if you can give that to them, they'll gladly share it.

Now, the author used that to do shady things with that. But the principle remains the same, You serve them some content that will get clicks, and they'll happily share it because it benefits them.

Here are the only books you need:

1. Smuggler's Cove: Exotic Cocktails, Rum, and the Cult of Tiki
   
   
2. Beachbum Berry's Potions of the Caribbean
   
   
3. Beachbum Berry Remixed
   
   
4. Beachbum Berry's Sippin' Safari
   
   They're all fantastic. But if you only buy one, start with Smuggler's Cove. It's just an incredible wealth of information and it's a lot more current than the others. It's also very useful if you're looking to expand your tiki repertoire since it has a lot of information on bar equipment, rums, syrups, etc. that the other books lack.

Ohh! You should definitely look into The Prize: The Epic Quest for Oil, Money, and Power by Daniel Yergin.

It depicts the history of the global petroleum industry from the 1850s through 1990.

Its extremely well written and an incredibly powerful part of human history.

Link: http://www.amazon.com/The-Prize-Quest-Money-Power/dp/1439110123

Just curious, is there a specific type of farm you're involved in?
You make a good point that there are many other arguable reasons. I've been vegetarian for over 15 years but only recently became interested in the potential environmental issues related to meat production after reading Eating Animals.
I would highly recommend the book to anyone interested in the topic of meat production in the U.S. I felt the author really tries to take an unbiased look at the industry and does a great job of offering different viewpoints. He has a chapter about pig farms that is particularly the most memorable regarding waste problems. Overall, though, he covers a wide range of other issues as they relate, including health, social, economic, and moral issues.

The suggestions here are good. In addition I recommend , 'Trust Me, I'm Lying': https://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285

This book gives you a good idea about the consequences of Postmodernism - at least, the toxic method of simply deconstructing anything to the point that nobody knows what is 'true' or even that some things might be more 'true' than other things.

Blood, Sweat, and Pixels! I've heard great things about this book from a friend of mine - a good behind the scenes look at how some games are made (or sometimes fail).

Guys, if you're interested in the making of Destiny, or stories like this in general, i encourage you to read Blood, Sweat, and Pixels. It is really good.

Book recommendation: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

This book is not directly related to agile. But it is rather unique, because it is based on studies and not on authors subjective opinion. It tries to figure out, which mechanics are relevant for modern software development teams.

Most often our rituals are not based on evidence. They are originally based on convenience and afterwards kept up as dogma. Sadly the original introduction was often done by the wrong people.

For example agile was mostly invented by developers, but the widespread adoption of scrum was done by business people (managers as scrum master). As such a dogma was formed that may not be in the best interest of solid software engineering.

Read Soccernomics.

The authors frequently return to Moneyball and how its principles can (and sometimes are) apply to football. It's also a really interesting read in its own right.

To answer your question more directly: Lyon is a great example discussed in Soccernomics. (thanks to /u/5uare2 for pointing this out).

Also, Damien Comolli (previously Director of Football at Liverpool, Spurs, Arsenal et al.) is a close friend of Billy Beane and used some of his ideas at the clubs he was working at to influence transfer strategies.

EDIT: words and stuff.

Only one title of overlap, nice.
Out of your list, where would you start? Have you read any other in our original list?



Built to Sell, John Warrillow

The Automatic Customer, John Warrillow

How to Sell at Margins Higher Than Your Competitors, Lawrence Steinmetz

Start With Why, Simon Sinek

Leaders Eat Last, Simon Sinek

The E-Myth Revisited, Michael Gerber

Selling the Invisible, Harry Beckwith

What Clients Love, Harry Beckwith

Question Based Selling, Tom Freese

Some of these are directly related to programming and some are not but are additional reading that touch on skills that most every programmer should have some concept or idea of.

I've read all of these at some point throughout my career and can attest to their usefulness. Here's my personal list:

• Rework
  
  
• Refactoring - Honestly, anything written by Martin Fowler.
  
• The Mythical Man Month
  
  
• The Phoenix Project
  
  
• The Goal - targeted towards manufacturing and production, but the lessons can be applied pretty much anywhere there's a process (anywhere).
  
  
• Programming Language Pragmatics
  
  
• The Traveling Salesman
  
  
• The Art of Computer Programming - This collection of books is a journey spanning many years. The problems presented in the book are ones you'll want to mull over for some time, and the type of problems that would be good to think about during a daily commute.
  
  
  

Soccernomics by Simon Kuper and Stefan Szymanski has been an interesting read so far, if you're interested in the business side of the game. Another good one was How Soccer Explains the World: An Unlikely Theory of Globalization, which was comprised of case studies that looked at all sorts of different trends in the game, not just globalization.

Both of those books are well-written and -researched and offer good insights, and give historical contexts for, trends in the game.

Well, this is a good book to start with and has a bunch of useful information in it. I would be willing to answer any specific questions you may come up with as well.

As far as coops, you need decent wire (chicken wire is too weak to keep some predators out) and at least one solid wall and a roof (I'm in Texas, so one wall to block wind is enough to keep them warm. The rest of the walls are just wire). You also need to sink the wire into the ground a few inches so animals can't dig under. I actually dug 6" trenches around mine and filled them with concrete.

For health concerns I recommend this book, it has a lot of good info in it and is not too technical.

Sounds kinda like some the work of Ryan Holiday, (former?) marketing head for American Apparel.

His book is pretty good: http://www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285

And a Bottle of Rum is absolutely the book you're wanting.

Smuggler's Cove has several decent sections on rum, including some history and a lot of subdivisions and classifications.

Potions of the Caribbean is another great book more focused on the influence of cocktails in the Caribbean, but has some good insights on rum as well.

I highly recommend The DevOps Handbook; I'm in the midst of reading it now, if you appreciated The Phoenix Project then this comes across super practical and to the point.

https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002

QBQ. The Question Behind the Question


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

Rework


Getting to Yes: Negotiating Agreement Without Giving In


Gemba Kaizen: A Commonsense, Low-Cost Approach to Management

Time Management for System Administrators

> For the agent provocateur, I am just pointing out that we do not know the details.The agent could either be from a law enforcement group or possibly a media outlet who wants a story. The book www.amazon.com/Trust-Me-Lying-Confessions-Manipulator/dp/1591846285 talks about how he went and slapped sexist posters around town and then took pictures of them to create a story.

Of course you'll never know the details. That is why you have to use your brain. What were the outcome for those involved ? Where those outcome predictable ? You can then probably assume that the predictable outcomes where the goals of the perpretretors and infer their motives / identity.

Have those threads resulted in a crackdown on videogame misogyny ? Have they helped the target or harmed/destroyed their (professional) life ?

>Personally I would say the elites have shifted from supporting the right wing to supporting the left wing since they see them as less of a threat.

The elite support both right-wing and left wings on social issues (gay marriage), so as to pretend that we have a healty democracy, laughing all the way to the bank.

Absolutely! Here's a short list of non-magic books that I commonly see recommended to magicians.

Understanding Comics - Scott McCloud

Purple Cow - Seth Godin

Delft Design Guide - multiple authors

An Acrobat of the Heart - Stephen Wangh (shouts out to u/mustardandpancakes for the recommendation)

In Pursuit of Elegance - Guy Kawasaki

The Backstage Handbook - Paul Carter, illustrated by George Chiang

Verbal Judo - George Thompson and Jerry Jenkins

Be Our Guest - Ted Kinni and The Disney Institute

Start With Why - Simon Sinek

Lots of common themes even on such a short list. What would you add to the list? What would you take away?

Progression systems, squad controls, over-the-shoulder third person, and expansive environments all needed to be adapted to make Frostbite work with Inquisition and Andromeda.

Check out Jason Schreier's Blood, Sweat, and Pixels for some additional information. He has an entire chapter on what the Inquisiton team had to do to adapt Frostbite for Inquisition.

I agree though, my favorite parts of Inquisition and Andromeda are without a doubt the environmental design and the technical prowess behind any type of magical/biotic/tech explosions. Those games at their best look as good as any game I've ever played.

In terms of bang for your buck, this is the best one out there. Not only does it have every recipe you could want, it also covers the why and how of every basic step. Published by the Culinary Institute of America (the best culinary school in the world.)
https://www.amazon.com/Professional-Chef-Culinary-Institute-America/dp/0470421355

Don't know what specific field you are in, but if you have an IT focus at all I STRONGLY recommend the Phoenix Project by Gene Kim and Kevin Behr. It's a non fiction approach to IT management wrapped in a fictional story. Anyone who has worked in any sort of IT related field will relate strongly to the first half of the book.

If you're serious, start here for understanding Energy. Then something much more light weight about Oil

Then you can read light edutainment like The Prize with more gain.

Info | Details
----|-------
Amazon Product | The Cannabis Grow Bible: The Definitive Guide to Growing Marijuana for Recreational and Medicinal Use
>Amazon donates 0.5% of the price of your eligible AmazonSmile purchases to the charitable organization of your choice. By using the link above you get to support a chairty and help keep this bot running through affiliate programs all at zero cost to you.

There are already some great ones posted so I'll just go with a couple more... non traditional ones that are surprisingly helpful.

Purple Cow

Start With Why

Moneyball is a book. This book.

Moneyball is also the theories espoused in that book. The book basically introduced the idea to the general public, that by truly understanding baseball statistics, teams could get an edge up on their competition and succeed while spending less. The book led to a statistical revolution in baseball, leading to the popularization of new statistics (like WAR, FIP) that were better predictors of future success than the old statistics (Runs, RBI) were.

u/the_jixxx - sounds like a classic case of a good developer throwing shit over the wall and unintentionally not being a team plater. I'd suggest reading this book as it describes EXACTLY the situation you are describing: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290

Your team/company will likely see a big benefit by moving to a more devops-style model of software development. Hope it helps you begin your journey

Good news bucketeers! The third edition of the Cannabis Grow Bible is finally out, a few weeks before expected. You can get it here on Amazon. Hopefully many readers of the book will check out our community!

Cheers

1. Go to a bar with a good selection of rums
   
2. Taste some rums that you and the bartender agree are dark
   
3. Have your mind blown at the variety of what you experience
   
   Others have recommended Martin Cate's book from Smuggler's Cove. Get it. :)

Huge baseball fan..

this looks like a great read!

Explosions are cool, man. What better justification do you need than that?

PS: happy independence day! Here's some light reading until boomtime. http://www.amazon.com/Everything-Want-To-Do-Illegal/dp/0963810952

You should read "Scorecasting." It's a really cool book that is comparable to Freakonomics from a sports standpoint.

Here's a blurb about home field advantage.

Basically, the authors think that Home Field Advantage seems to come from referee bias and not that the crowd makes the players play better. That said, I don't know what happened to the Jets that weekend, but I see it as more of an anomaly and would be comfortable starting Asiata, McKinnon to a lesser degree.

Good question. He has written some very fine books. I particularly enjoyed Everything I Want To Do Is Illegal.

Look at the replies to your post. It really wasn’t funny.

Do some research. Crunch is real, it happens a lot in the industry. I don’t think NetherRealm has denied it either. Here’s a good book that shares a lot of stories about crunch and how damaging it can be:

Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made https://www.amazon.com/dp/0062651234/ref=cm_sw_r_cp_api_i_5nooDbZGYAZP0

Pretty sure the crybabies in this scenario are the people whining they’re not getting their DLC fast enough.

I was excited by the Culinary Institute of America's The Professional Chef. http://www.amazon.com/Professional-Chef-Culinary-Institute-America/dp/0470421355/ref=zg_bs_4254_20

This looks more creative and scientific. Congrats.

Hit the public library and get a book. They'll no doubt have a bunch, especially if you live in a hipster backyard chicken area. Once you go through several, purchase the one you like best. Storey's is excellent, IMHO, as it is more "realistic" and less hobbyist. http://www.amazon.com/Storeys-Guide-Raising-Chickens-Edition/dp/1603424695

Over a website or blog, you might find a hard copy more convenient, as you can put post-its in it, take it to the store more easily, bring it out into the yard while working on the coop, etc.

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.