> (I only know small bit of Python and C++ and quite good Bash, I've been looking into expanding Python knowledge and learning Java), I only have experience in Linux for around 5 years (I use terminal mostly for my stuff).

That puts you a head of quite a lot of people out there.

> I am currently 15 years old

... a lot of people.

Keep learning, you will do fine. You will not find it hard to get a job when you are older if you keep this pace up.

----

> what programming languages are recommended to learn

Really any of the major ones that you enjoy. At this stage you may want to play around with a few different ones to get a feeling for them, or your can pick one and focus mostly on it. It is good to know multiple different languages as each give you a different perspective but you should spend most of your time learning one or two main ones.

All the languages you have listed are good choices, but I would throw Go and/or Rust as a suggestion as they are both growing in popularity and both offer a nice new way to look at languages. Javascript is generally worth learning as it is the corner stone of web development and most DevOps projects are at least partly if not mostly web based.

> what are my tasks as DevOps

Keep in mind DevOps is a bit of a misleading catch all buzz word these days. Really I prefer to think of my self as a full-stack developer with a focus on infrastructure and automation. But DevOps roles vary wildly from general problem solvers to pure Ops people to cloud architects to CI pipeline builders (often multiple roles). So the specific tasks vary and generally you have some freedom to pick the position you enjoy the most.

What makes someone really good at DevOps is having a higher level understanding of the business, processes and how everything fits together while having detailed enough knowledge to implement specific things. And, possibly more importantly, being able to lead/teach a team to constantly improve.

But most of that comes from experience. First you should learn the process as a whole. Remember: The goal of every software team is to get value (features/bug fixes etc) to the customer as fast and safely as possible. So I would work towards this. Create some simple application, deploy it to some infrastructure. Look at the process you took to do this and ask your self, What did you find hard? What could you improve? Then find a better way to achieve your goal and iterate. Improve on this process over time, introduce a new bit of technology to help solve the problems you face and read up on how others have solve the problems you have faced. Keep learning and improving.

There is quite a lot to learn, there always is, so I would focus on the bits that give you most value for a given task and try to avoid learning more than one new thing at a time (it is very easy to become overwhelmed with everything).

As for environments to deploy to, AWS is a top choice. It is very popular in enterprise and offers a tone of services. But it can be expensive for some workloads. It does offer a free tier (some things for 12 months, others forever) so I would encourage you to create an account but be wary of what you can do (it is very easy to rack up a huge cost if you are not careful - just yesterday I was playing around with EKS and managed to spend $10 in a single day for a single experiment).

GCP is also worth a look at and offers $300 in credit for 12 months and has some always free resources.

Making cleaver use of these services you can do quite a lot with very little (or no) cost to you. Things like AWS lambda and S3 buckets (and the google equivalents) give you some generous free limits if you design applications to take advantage of them.

Digital Ocean is another great one to use - cheaper ($5 a month for their smallest instance) and simpler than AWS and GCP with $100 credit for 60 days with a referral link.

Vultr is another good one about the same price as DO but with a smaller (and cheaper) base instance at $2.50 (ipv6) (or $3.50, ipv4) node.

All of these services charge by the hour so you can stretch the free credits and tiers quite far (ie for a few years) if you are careful to manage them.

There are also other services like netlify and firebase (part of GCP) which offer free static site hosting and lambda/auth/form services for free to a limit which will allow you to build and deploy some applications for free.

> If you recommend me a book

For a start:

• The Phenoix Project
  
• The DevOps Handbook
  
• Site Reliability Engineering

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.

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.
  

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep

1. Cracking the Coding Interview: 189 Programming Questions and Solutions
   
2. Programming Interviews Exposed: Coding Your Way Through the Interview
   
3. Introduction to Algorithms
   
4. The Algorithm Design Manual
   
5. Effective Java
   
6. Concurrent Programming in Java™: Design Principles and Pattern
   
7. Modern Operating Systems
   
8. Programming Pearls
   
9. Discrete Mathematics for Computer Scientists
   
   

   Junior Software Engineer Reading List
   

   
   

   Read This First
   

   
   

10. Pragmatic Thinking and Learning: Refactor Your Wetware
    
    

    Fundementals
    

    
    

11. Code Complete: A Practical Handbook of Software Construction
    
12. Software Estimation: Demystifying the Black Art
    
13. Software Engineering: A Practitioner's Approach
    
14. Refactoring: Improving the Design of Existing Code
    
15. Coder to Developer: Tools and Strategies for Delivering Your Software
    
16. Perfect Software: And Other Illusions about Testing
    
17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application
    
    

    Understanding Professional Software Environments
    

    
    

18. Agile Software Development: The Cooperative Game
    
19. Software Project Survival Guide
    
20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
    
21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
    
22. Rapid Development: Taming Wild Software Schedules
    
23. Peopleware: Productive Projects and Teams
    
    

    Mentality
    

    
    

24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
    
25. Against Method
    
26. The Passionate Programmer: Creating a Remarkable Career in Software Development
    
    

    History
    

    
    

27. The Mythical Man-Month: Essays on Software Engineering
    
28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
    
29. The Deadline: A Novel About Project Management
    
    

    Mid Level Software Engineer Reading List
    

    
    

    Read This First
    

    
    

30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth
    
    

    Fundementals
    

    
    

31. The Clean Coder: A Code of Conduct for Professional Programmers
    
32. Clean Code: A Handbook of Agile Software Craftsmanship
    
33. Solid Code
    
34. Code Craft: The Practice of Writing Excellent Code
    
35. Software Craftsmanship: The New Imperative
    
36. Writing Solid Code
    
    

    Software Design
    

    
    

37. Head First Design Patterns: A Brain-Friendly Guide
    
38. Design Patterns: Elements of Reusable Object-Oriented Software
    
39. Domain-Driven Design: Tackling Complexity in the Heart of Software
    
40. Domain-Driven Design Distilled
    
41. Design Patterns Explained: A New Perspective on Object-Oriented Design
    
42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
    
43. Refactoring to Patterns
    
    

    Software Engineering Skill Sets
    

    
    

44. Building Microservices: Designing Fine-Grained Systems
    
45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
    
46. NoEstimates: How To Measure Project Progress Without Estimating
    
47. Object-Oriented Software Construction
    
48. The Art of Software Testing
    
49. Release It!: Design and Deploy Production-Ready Software
    
50. Working Effectively with Legacy Code
    
51. Test Driven Development: By Example
    
    

    Databases
    

    
    

52. Database System Concepts
    
53. Database Management Systems
    
54. Foundation for Object / Relational Databases: The Third Manifesto
    
55. Refactoring Databases: Evolutionary Database Design
    
56. Data Access Patterns: Database Interactions in Object-Oriented Applications
    
    

    User Experience
    

    
    

57. Don't Make Me Think: A Common Sense Approach to Web Usability
    
58. The Design of Everyday Things
    
59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
    
60. User Interface Design for Programmers
    
61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos
    
    

    Mentality
    

    
    

62. The Productive Programmer
    
63. Extreme Programming Explained: Embrace Change
    
64. Coders at Work: Reflections on the Craft of Programming
    
65. Facts and Fallacies of Software Engineering
    
    

    History
    

    
    

66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
    
67. New Turning Omnibus: 66 Excursions in Computer Science
    
68. Hacker's Delight
    
69. The Alchemist
    
70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
    
71. The Information: A History, A Theory, A Flood
    
    

    Specialist Skills
    

    
    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
    
    

72. Peter Norton's Assembly Language Book for the IBM PC
    
73. Expert C Programming: Deep C Secrets
    
74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
    
75. The C++ Programming Language
    
76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
    
77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
    
78. More Effective C#: 50 Specific Ways to Improve Your C#
    
79. CLR via C#
    
80. Mr. Bunny's Big Cup o' Java
    
81. Thinking in Java
    
82. JUnit in Action
    
83. Functional Programming in Scala
    
84. The Art of Prolog: Advanced Programming Techniques
    
85. The Craft of Prolog
    
86. Programming Perl: Unmatched Power for Text Processing and Scripting
    
87. Dive into Python 3
    
88. why's (poignant) guide to Ruby

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!

The best single resource, IMO, is The Devops Handbook.

Devops is a spectrum subject, like photography or design. Yes, a professional photographer would commonly use PhotoShop, LightRoom, and a Canon EOS 1D. But you don't become a photographer by using those tools, you become a photographer when the tools are solutions to what you want to accomplish.

Similarly, you don't "do devops" by simply building a Docker enabled CI/CD pipeline. You're doing devops when you create measurable visibility for productivity, when you create organizational memory and learning among teams, when you create autonomy and cohesion among engineers -unobstructed by meaningless process- to build a sustainable, performant and competitive product.

It helps to understand that devops is a largely a product of large corporations facing the challenge of maintaining a complex product which must always be available, secure, bug free (as possible) and performant over the course of years. And they must manage anywhere from a 4 person team to thousands of engineers who are constantly working on the product, and intrinsically challenging every one of the attributes above.

To that end, there are tenants of devops, more than there are hard rules, far too numerous and deep to cover in a reddit comment, but here are some surface level answers to your questions...

Basic workflow starts with TrunkBasedDevelopment. Everyone constantly publishes to master. This is typically achievable by having a set of (integration) tests run on each pull request to ensure the code is deployable. The level of testing done varies considerably for each corporation. Typically, unit testing is a minimum requirement, but there are security, performance, UI, QA and more.

It's important in devops that each developer is provided with immediate and thorough feedback. Tests and failures should happen quickly. If a developer is waiting for two hours each time new code is pushed, it decreases productivity. If messages or failures are unclear, this is also a detriment.

When tests are successful, and the pull request is granted, your code is merged in to master. This is the "delivery" end of continuous delivery.

"Deployment" is sending the code to production so its publicly available. This process varies tremendously by company, and even by project. Common approaches are "blue/green" and "canary" deployments which deliver the new code to a specific percentage of traffic to help find bugs before full deployment, test performance (make sure new queries don't kill the database when thousands of users hit it, for instance), or sometimes conduct marketing tests (A/B testing).

Engineers should also have simple access to perpetual, easy to understand feedback on the quality of their services after deployment, ranging from usage statistics, to performance, to failures. Again, plenty of tools available to help with this, but the end result of helping engineers refine the product is the goal.

Docker: In the theme of understanding devops, it might help to understand the problems being solved by Docker. They're numerous, and this is not exhaustive.

Docker is a "container" technology, but it's not the only one, it's just the most popular. Like what Kleenex is to tissues.

"Containerizing" your code means you deliver everything needed to run your code. This has cascading effects when it comes to operations:

It bundles all the configuration needed with your code. Before Docker, you would install xampp on your local machine in order to run the code base. Then, push it to a server, which had all of the configuration needed for its respective environment (e.g. dev, stage, live).

In this scenario, you're running an approximation of the live environment on your local machine. You have a different OS, maybe a different version of PHP, a different php.ini. Maybe production is running Nginx, and you're running Apache locally.

With Docker, your code is packaged, so your local development gets pushed to production and runs that way, as-is. Your nginx version and configuration, your php version and configuration, etc.

This has cascading benefits:

• It's far simpler and more robust to setup local development (once your Docker image is setup). New team members can be provided quick, simple to understand instructions, and have the exact environment the rest of the team has, in moments.
  
• It abstracts the server configuration away from the code configuration. So, if you want to run a Python 3 app, a PHP 7.1 app and a PHP 7.4 experiment on the same server, you can do so safely and easily.
  
• Version updates, security updates and patches to the OS and languages no longer need to be delicately performed on live servers. They can be built and tested locally before deployment (and in the pipeline, if setup correctly).
  
• Updates to entire operating systems or language version are often as simple as switching out version numbers in the build process.
  
• All of your changes can now be captured in your github repo. Now we can track down the exact date an OS update or language version update was made, and we can easily roll back if it causes issues.
  
• It provides deployment flexibility (the aforementioned blue/green and canary deployments), and since most container builds are stored in their own repo, it's simple to redeploy a known working copy in the event of a critical bug deployment.
  
• Containers -or properly containerized apps- are easier, more granular and more efficient to scale. When everything is properly containerized, you can simply deploy more containers of the service receiving the most demand, instead of deploying more servers and code, just because of a specific subset of functionality.
  
  That's all I have energy for. There's a lot, lot more. Hopefully that helps somewhat.
  
  TL;DR Read The Devops Handbook.

Here are all the books with amazon links, Alphabetical order :)

---

• Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant by W. Chan Kim et al. Link: http://amzn.com/1591396190
  
• Delivering Happiness: A Path to Profits, Passion, and Purpose by Tony Hsieh et al. Link: http://amzn.com/160941280X
  
• Essentialism: The Disciplined Pursuit of Less by Greg McKeown Link: http://amzn.com/0804137382
  
• Founders at Work: Stories of Startups' Early Days by Jessica Livingston Link: http://amzn.com/1590597141
  
• How Google Works by Eric Schmidt et al. Link: http://amzn.com/1455582344
  
• Jab, Jab, Jab, Right Hook: How to Tell Your Story in a Noisy Social World by Gary Vaynerchuk Link: http://amzn.com/006227306X
  
• Losing My Virginity: How I Survived, Had Fun, and Made a Fortune Doing Business My Way by Richard Branson Link: http://amzn.com/0307720748
  
• Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath et al. Link: http://amzn.com/1400064287
  
• Mindset: The New Psychology of Success by Carol Dweck Link: http://amzn.com/0345472322
  
• Never Eat Alone, Expanded and Updated: And Other Secrets to Success, One Relationship at a Time by Keith Ferrazzi et al. Link: http://amzn.com/0385346654
  
• Relentless: From Good to Great to Unstoppable by Tim S. Grover et al. Link: http://amzn.com/1476714207
  
• Rework by Jason Fried et al. Link: http://amzn.com/0307463745
  
• Talent is Overrated: What Really Separates World-Class Performers from Everybody Else by Geoff Colvin Link: http://amzn.com/1591842948
  
• The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich by Timothy Ferriss Link: http://amzn.com/0307465357
  
• The Choose Yourself Guide To Wealth by James Altucher Link: http://amzn.com/150100994X
  
• The Difference Between God and Larry Ellison: *God Doesn't Think He's Larry Ellison by Mike Wilson Link: http://amzn.com/0060008768
  
• The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz Link: http://amzn.com/0062273205
  
• The Innovator's Dilemma: The Revolutionary Book That Will Change the Way You Do Business by Clayton M. Christensen Link: http://amzn.com/0062060244
  
• The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries Link: http://amzn.com/0307887898
  
• The Millionaire Fastlane: Crack the Code to Wealth and Live Rich for a Lifetime by MJ DeMarco Link: http://amzn.com/B004BDOUAI
  
• The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph by Ryan Holiday Link: http://amzn.com/1591846358
  
• The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results by Gary Keller et al. Link: http://amzn.com/1885167776
  
• The Startup Owner's Manual: The Step-By-Step Guide for Building a Great Company by Steve Blank et al. Link: http://amzn.com/0984999302
  
• The Tipping Point: How Little Things Can Make a Big Difference by Malcolm Gladwell Link: http://amzn.com/0316346624
  
• Traction: How Any Startup Can Achieve Explosive Customer Growth by Gabriel Weinberg et al. Link: http://amzn.com/1591848369
  
• Unlabel: Selling You Without Selling Out by Marc Ecko Link: http://amzn.com/1451685319
  
• Zero to One: Notes on Startups, or How to Build the Future by Peter Thiel et al. Link: http://amzn.com/0804139296

Thanks for your insight and wisdom, that is really what makes reddit great and internet forums in general. Someone like me being able to learn and discuss with someone like you. And hopefully the other way too, so that we all are enriched and the community benefits.

Kevin was around back in those years, with his nose to scene, but I wasn't. Do you feel there was anything good that came out of all that sega experimentation, even if it didn't directly benefit sega? Maybe it helped other companies, other tech in the industry, or just certain people who got good ideas or knowledge off of sega's mistakes? Was there anything positive that came of it in anyway?

I used to work at IBM, I was told to read some books, http://www.amazon.com/Blue-Magic-Politics-Personal-Computer/dp/0816013918 , and game over, http://www.amazon.com/Game-Over-Nintendo-Conquered-World-ebook/dp/B0060AY98I/ref=sr_1_7?s=books&ie=UTF8&qid=1426550681&sr=1-7&keywords=game+over and many other books, to learn the history of companies from various perspectives, I always like to read and learn more, can reco any books on sega history?

Losing the money badly, do you think if they had say, a 2 billion dollar cushion like Oculus supposedly does today, to just test all kinds of hardwares, softwares, just burn through zuckers money at free abandon kinda, could they have kept squandering it to a point where they began to make money? If so, speculating of course, how much money do you think Sega should have needed back then to turn it around? Do you think that 2 billion oculus has today, can keep them competitive to the likes of steam, msft, apple, google, etc, is 2 billion all that much against such competition? Carmack had strongly suggested he wanted minecraft for oculus, well now MSFT bought that IP, steam has Half Life 3d more than likely, so just from a computer historian point of view, I am interested in learning all this history, even as it is happening, and peoples view points on it.

I never bought any of the systems you mentioned, the dreamcast was the only one that interested me. What do you think sega could have done to not get developers to hate them, and again your speculation is useful, because maybe the ideas you have could be used by people/companies today, to not make those mistakes again. Could sega have been more supportive of developers? I will not name names, but I would like you to know some general stories I am hearing right now, about various solutions of many things. The developers have hardware in their hands, some of these KEY AAA developer types. And they see problems in various softwares, so they want to fix these problems, well one company has closed source the softwares, and wont share the code, so the developers had to go through this one key programmer that is the code master at the company to suggest changes, (lets call him carmack, but that is just a placeholder name, in no way am I saying it is oculus or carmack in this thought experiment) here is the problem though today, this carmack code master decided he wanted to get paid a higher salary for all the slave code work that was being heaped upon him by all these new issues, and he went to his bosses, give me raise! They are saying FU, we can get a billion coders from india and china to replace you for pennies on the dollar!! So what I am hearing is he is getting mad, and he is one of these code masters that believe in job security, so he didn't document code very well, in fact he may have done lots of tricks in his code to even make his job more secure, I understand the code masters reasons for doing things, I understand the companies reasons for doing things (closed source wise), I understand the developers frustrations that they can't make progress because of these things, but the rest of us, the consumers, are all being hurt by this apex of scenarios. What is the solution from the macro scale, to best benefit the most number of people?

As to reputation, I agree it is very important, people want to feel they are being treated somewhat with freedom, respect, dignity, decency, like a human being and a gentleman. They dont like to feel they are being dictated to by a tyrant, controlled, lied to, backstabbed, used, threatened. Kevin has tried to advise time and time again to certain companies NOT to make the mistakes of the past, the mistakes of previous cycles of VR, the mistakes of a Sega, and he sees them being made again, and so few will listen at sage advice like his, and yours, to consider the past, learn from it, or be doomed to fail from repeating it. I have tried my best to impart to many companies, and even certain people in those companies, how IMPORTANT it is to listen at people like you, people like Kevin, for just reputation affects alone, and they seem to not wish to do so.

I have often said, what does it gain a Padawan Palmer to own the whole neuromancer metaverse, if you snowcrash your soul? I guess the big takeaway, if people don't like your reputation, they will just stop working with you, and that could hurt the whole industry, where we could instead have bridges built and cooperation that does well for the whole industry to benefit us all. Thanks for your time, I appreciate it greatly.

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.
  

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.

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
   

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!

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

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

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.

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

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.

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.

Yes, most scientists (but not all) do believe in an AI singularity. And when polled AI researchers' have a median prediction of that occurring within 45 years.

The idea is that once you've created an AI smarter than us (or at least better at AI programming) it will be able to program a better AI than us. Since we were able to program it and it is better at programming AIs, it will be able to program a better AI than itself. You would then have iterative generations each one smarter than the previous.

Some things to note however is that this won't be infinitely smart. Physics puts some upper limits on how much information can be processed how quickly and with how much heat and entropy. That being said those limits are huge and scientists don't know how much smarter it'll be than us. But even the idea that it could be just a little bit smarter than us but that you could network a bunch of brains just slightly smarter than us together is pretty scary.

Scientists also don't agree on how much of a risk this poses to humanity, but most believe it is a risk that needs to be taken very very seriously. But many also believe it is a risk that when taken very very seriously can be properly managed. Look at how successful Bezos or other Billionaires are. An AI like this could absolutely run the world if it wanted. And forget about shutting it down. It would be smart enough not to do anything that would scare us enough into shutting it down until it had protected against that possibility.

Where the world ends up after the AI singularity depends so much on the goals of that initial AI superintelligence.

For more information on AI's check out this computerphile video. That researcher has about 10 or so videos on computerphile on the same subject. If you want a really in depth view on the state of AI super intelligence, I'd recommend Life 3.0 which is by an AI researcher who has been organizing AI saftey conferences and been working with Elon Musk and others to fund AI researchers' work. They discuss what are the different types of scenarios we could end up with and asks interesting moral questions about where we want to end up. For example, do we want to be in a world where nobody has to work or would that lead to lack of fulfillment in people's lives? Would we want an AI who would only minimally interfere and mainly function to prevent malicious AIs from emerging? Or would we want one that would push the frontiers of science for us?

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

I'm partial to Cloudera or Horton Works. Both have training courses.

• Cloudera (note they have a course tailored specifically for data analysts)
  
• Horton Works
  
  I personally like good 'ol books. I've taken the Coursera intro and Hive/Pig training courses and while they were invaluable, nothing quite replaces sitting down and working your way through books like Hadoop: The Defininitive Guide or MongoDB: The Definitive Guide. I highly recommend Safari Books Online if you enjoy online reading. Perhaps some of your professional development money could go to paying for an account for that. For those who don't have the money for that, don't underestimate the usefulness of your public library. I currently have 3 books out from my local library on graph/network science (Linked is awesome and a great start for anyone interested in Networks/Graphs).
  
  One thing I'll mention is that Hadoop has really become more of an ecosystem than a produce. HDFS, MapReduce, Pig, Hive, Sqoop, Flume, HBase, Storm, etc. Just saying "Hadoop" is like just saying JQuery. Half the battle with JQuery is knowing how to use the best plugins. It's the same with Hadoop.

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!

> 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

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.

In general every path is different, so take all advice with skepticism. Study of entrepreneurship has shown that reality differs from traditional teaching. For example, business plans tend to be used after the fact for improvement rather than seriously up front. This is covered well on Effectuation. The E-Myth books cover important basics, though most of those books say the same things and it does not always apply. Paul Orfalea's Copy This is pragmatic and inspirational. An old but still good book with various lessons about doing business is Startup by Jerry Kaplan. The book Founders at Work has lots of real stories that drive home how much work startups are and how different and in a way alienating the work can be, as starting something is not like having a job.

For ideas and inspiration in general the Change This site can be a good source. Good luck!

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!

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

> The self driving car is a creative industry, that depends on creative problem solving within a specific domain.

Not sure your background? But you really do not want to run your software engineering organization like this.

You really want it to be more like a system. You really never want to be dependent on any one person.

You want to put together the processes such that you are not dependent on any single person. There is an awesome book on this.

Well there is a series but if into software engineering I would first read the Phoenix Project and then read the Google SRE book.

https://www.amazon.com/dp/B078Y98RG8/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

Or read the first one then Phoenix project and then the Google SRE book. They all go together. The first one is called the Goal. That is how I did it. It will change your way of looking at things.

Waymo is applying what R&D done at Google brain and with DeepMind.

Google is where the AI breakthroughs come from and then applied by Waymo. So where AlphaGo and AlphaStar and GANS and capsule networks and word2vec and TF and a zillion other things.

Google shares this research at NerulIPS. As you can see they lead in papers accepted. This is a year old as we do not have the new numbers yet. But as you can see Google is way out in front.

Google's AI Research Dominance Shown via NIPS Papers -

https://medium.com/machine-learning-in-practice/nips-accepted-papers-stats-26f124843aa0

But ZERO from Waymo. As it should be. Waymo is applying the R&D done.

BTW, this is the old and disgraceful name. It has been changed because of leadership from Nvidia and Google. It is now NeurlIPS.

> It doesn't matter that they're furthest ahead at the moment, there is currently no thing under Waymo's roof that is irreplaceable.

It does matter. Because Waymo has to use to get to scale and that is your moat. The self driving aspect will be replicated. You secure your spot by having scale. Scale can't be easily replicated.

It is why I keep harping on the business model of MobilEye is a very weak model. Reason is they are behind the scenes. They do NOT have the customer relationship. It makes it so you can be easily replaced. It gets you weak margins. Low multiples.

Perfect example is MobilEye won Tesla business. Messed up and killed someone. Then was fired and Tesla doing their own. They got nothing out of it. But a blemish on their reputation.

ALL the "breakthroughs" comes from Google including DeepMind. That is how it is supposed to work and is working. Waymo is responsible for applying those "breakthroughs" as you indicated applied science.

But it is done using the model from the Goal, Phoenix Project and applied with the principles from the Google SRE book or some other DevOps book.

Google has done this for a long time better than anyone else. They literally have written the book. It is how they have been able to achieve not a single quarterly decline since day 1 and through the greatest recession in my life time. They are now growing at 20%+ for the last 10 quarters without any end in site and a big part is using these principles.

https://www.statista.com/statistics/267606/quarterly-revenue-of-google/

How everyone today runs their clouds was invented by Google and shared through papers. It was done by creating a new approach. It is why when you wake up in the morning and type Google it always works. If it did not you would think something huge must have happened in the world. That there is much bigger issues than Google not working.

That would never work if Google was dependent on a person. Let me know if this helped. I hope you consider reading the books. Or listen to the books.

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.

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.

This game looks awesome! Truly, truly. Be sure to post about it in /r/IndieGaming.

Spend the time on it; read the chapter in Blood, Sweat, & Pixels about Stardew Valley, then get the game right.

Cheers and best to ya.

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!

Thanks for asking. Very often our (hopefully undeserved) reputations keep others from asking us anything.

There are many good answers here, but if you wish to know how Christiany became dominate, perhaps you would enjoy the explaination in Linked: How Everything is Connected and What it Means.

What is really interesting (not in the book) is what happened to the Roman priests, or what didn't happen. It seems they just switched to being Christian Priests, in many cases they didn't even change their ceremonies or messages! Fun stuff.

Somebody in another comment mentioned Kevin Mitnick.

In addition to Mitnick's book, I'll also recommend:

Steven Levy's Hackers. It's a classic exploration of the birth of the computer age and hacker culture, with a lot of insights into the mindset of computer people, both white-hat and black-hat.

The Cuckoo's Egg by Cliff Stoll, which is an account of him tracking down some serious hackers waaay back in the day. It's kind of vintage now, but I remember it being very well written and engaging. It's more like reading a novel than some dry academic piece.

In similar vein is Takedown, by Tsutomu Shimomura, which is Shimomura's account of pursuing and catching Kevin Mitnick. Also quite good, as it was co-written by John Markoff. There's a whiff of Shimomura tooting his own horn in it, but you definitely get a feel for the chase as it was happening, and learn a lot about the details of what Mitnick (and others in the underground hacking world) were actually doing.

Weird fact: I had no idea at the time, of course, but during some of Mitnick's last days before they nabbed him, he lived in an apartment building in my neighborhood in Seattle, right across from the grocery store where I always shopped. And about a year later, I ended up dating a girl who lived in that same building at that time, though of course she had no idea Mitnick was there either or even who he was. Still, I always wonder if I ever happened to stand next to him in line at the grocery store or something like that.

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

> 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

As a short-term goal, I would say creating AGI, which should lead to the technological singularity. I like to believe that once that happens, what we have created (and has self-improved) will be "smart enough" to solve things that will (at that point, not now) be "trivial" for it: climate change, poverty, war, free energy, etc

I started reading Life 3.0 14 months ago (switched from reading the book to listening to the audiobook a couple months in). I'm deliberately reading it slowly (and often going back to re-read slightly before where I left off) so I can savor it

I would love if everything turned out as awesome as that book paints a picture of humanity's future

Post-singularity, the possibilities are (nearly) endless: colonize Mars and several moons, maybe a few O'Neill cylinders and then spread throughout the galaxy (either in person or sending out robot ships while we all relax in our own VR worlds)

I've read many video game history books, they all have this anecdote in them but none have any real proof. However, the NES originally launched in New York City and Nintendo had to make the promise to stores they'd buy back all unsold stock. So that does help support the claim a little.

btw, Game Over is an awesome read.

If you do TnM you will never have any leverage in the business. Even if you're a one man show you'll struggle to take a vacation. If you build a large business your revenue will always be trading dollars for hours.

The MSP model, while tougher to get started, will get you much further in the long run. You should try to create 3-6mths of buffer to get started, it won't happen overnight, but don't get discouraged. You can shorten this period if you win a client before leaving your current job.

This doesn't mean you can't build up some TnM clients before you start to sell an MSP offering, just don't get stuck there forever.

• Build your plan
  
• Determine your pricing
  
• Talk to everyone you know about what you can do for their technology needs
  
• Prosper
  
  I have a blog post about what the "best" MSP pricing model is you can check it out here.
  
  Karl Palachuck has this book that would be helpful. The book has some specifics about what to include and how to price etc.
  
  Tech Tribe would be useful as well. Currently closed, but can register for the waiting list. Tech Tribe is run by Nigel Moore, who you can listen to interviewed here. He also has a book coming out that details the specifics of building a pricing plan.

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.

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

>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

You can download the Etherium Wallet here where you can at least start taking a look at some dev tools. This was also posted on /r/ethereum yesterday and it mentions Truffle which seems like a pretty great resource. Learning JavaScript will be helpful. Oh, and I just remembered there's a humble bundle happening right now that includes a book on Solidity and Ethereum (although you can get just that book as a Kindle version for ten bucks on Amazon). I haven't personally started doing anything with Solidity though, so I can't vouch for how great these resources are. Just passing along the information that I've seen in the last couple days.

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.

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

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.

The Book, Debugging Teams is fairly short and creates some super great, easy to implement, powerful skills for any manager or team.

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

It is. Really good book. Long, super detailed. I got my copy back in the early 2000s but never finished it. After Hiroshi Yamauchi passed away, I dug it up and re-read it in full. Really glad I did.

It's long out of print, but there might be some used copies floating around. I did notice it's on Kindle:

http://www.amazon.com/Game-Over-Nintendo-Conquered-World-ebook/dp/B0060AY98I/

Totally worth $10, a must read for any Nintendo fan.

In my mind, a DevOps PM is a technical role responsible for aligning project management (scrum masters), technology strategy, and developers. If the business says 'we want to push new code every 2 weeks' and 'we want the ability to A/B test different features,' it's up to the DevOps PM to make sure that the product is architected in such a way that this doable, make sure project management understands the challenges, track velocity for new releases, etc.

I'd recommend reading The Phoenix Project to learn more. A little outdated given the rise of cloud computing and microservices, but the ideas around agile and finding the most efficient way to release code still hold true today.

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.

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

I'm going to suggest a few books that aren't textbooks that'll teach you a specific topic but are certainly brilliant at passing on viewpoints that are beneficial to your overall understanding of computer science and software development.

• Dreaming in Code
  
  
• Godel, Escher, Bach
  
  
• The Mythical Man Month

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.

I think people will dig my book not just because it's super cheap (PLUG!!!) but because it's got a bunch of stories that have never been told before. I'll likely be doing more publicity (AMAs etc) closer to then but I hope people enjoy it!

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

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?

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

You're going to find yourself in a position where you'll need to communicate external dependencies to your team, and also where you'll need to communicate the work you do outward. Focus on how you can deliver these messages in the most effective manner so that everyone hears them.

Develop a culture of rigor. If you want a product that's stable, secure, performant, and maintainable, you should state that very clearly, and bring all your internal discussion back to those tenets. If you don't have them already, invest in testing, real-world monitoring and error reporting, and code review.

Code review is the worst place to make architectural decisions. It's expensive and difficult to make changes when you catch them at this stage. If you're catching architectural issues at code review, it means you don't have enough process up front to design the system/code correctly.

It's a powerful thing to say "I don't know" or "I was wrong". You'll develop a trust with your team that they can depend on you to be searching for the right answer, even when you don't know.

Have a weekly "dev team meeting". Having a forum every week where you can talk about the tactical approach to the project can be really helpful. As the name suggests, keep it to just the dev team, and possibly the manager if they are extremely technical and directly involved in helping the team execute on the project.

Finally, I can't recommend this book highly enough. It's a quick read, and you'll come back to it many times. https://www.amazon.com/Debugging-Teams-Productivity-through-Collaboration/dp/1491932058

I've recently been reading this book:

http://www.amazon.com/Founders-Work-Stories-Startups-Early/dp/1590597141

which is full of anecodtes about the early days of Adobe to Yahoo (including reddit favourites like Viaweb and Fog Creek). It's interesting reading (better than tryint to find another nuggest of wisdom in the latest AJAX book :) )

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.

It's on my reading list, but I've heard good things about https://www.amazon.com/Life-3-0-Being-Artificial-Intelligence/dp/1101946598. It's a non-fiction book that looks at the effects AI will have on the world. I'm also writing about an AI, and I hope this book helps my understanding as well.

Beyond that and the suggestions I've seen below, Westworld is another show with AI in it to check out.

> What is to truly do?

Dunno. But, I've been retired for a while now and am seriously enjoying it!

I went to a lecture and book signing, but haven't yet read the book, called
Life 3.0: Being Human in the Age of Artificial Intelligence by Max Tegmark. It explores this topic in depth.

We need to, at a minimum:

1. Make sure that the robots' goals are aligned with ours. We wouldn't want, for example, a society led by robots who were negative utilitarians and decided to reduce human suffering by eliminating humans. Well, most of us wouldn't want that. Me? Sometimes.
   
   
2. Make sure that the wealth generated by the huge productivity of robots is considered a societal resource, not something that belongs only to the owners of the corporations that own them. With no human jobs, we will need, at the very least, some form of a universal basic income.
   
   
3. We need to stigmatize autonomous killing robots the way we do with chemical and germ warfare. We definitely do not want a world that contains slaughterbots.
   
   There were many more points on the topic that were made by Max Tegmark at the lecture. I expect there are even more in the book. When my wife is done with it, I'll start reading it.

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.
  
  
  

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

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?

I've read Introducing Ethereum and Solidity and it pretty good.

I'm working on a tutorial on how to create a DApp using React and Solidity that I will post on my blog. If you are interested, you can subscribe to get an email when I publish it.

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.

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.

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

The only book that I've read (currently reading) is Managed services in a month, haven't got to the part where they (if they) talk about that stuff. You're well established so I'm not sure if it would help you.

Still a GREAT book! Here's the link:https://www.amazon.com/Managed-Services-Month-Successful-Business/dp/0981997856/ref=sr_1_1?s=books&ie=UTF8&qid=1473283679&sr=1-1&keywords=managed+services+in+a+month

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

I recently read this book:

https://www.amazon.com/gp/aw/d/B06XQFYL2M/ref=tmm_kin_title_0?ie=UTF8&qid=1491480820&sr=8-1

It actually addresses both of your posts and describes, in great detail, what makes ETH so special in comparison with BTC.

There are TONS of additional resources for learning Solidity online, as well. It's an easy language to learn.

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

These look great - I'm buying them asap.

Amazon recommends a third book as well: "Leading the Transformation: Applying Agile and DevOps Principles at Scale".

• https://www.amazon.ca/Phoenix-Project-DevOps-Helping-Business/dp/0988262509
  
• https://www.amazon.ca/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
  
• https://www.amazon.ca/Leading-Transformation-Applying-DevOps-Principles/dp/1942788010

Taking the plunge to get rich on the other side of the crypto game.

Ordered Introducing Ethereum and Solidity: Foundations of Cryptocurrency and Blockchain Programming for Beginners

I've got some CS background and an aptitude for programming. As a mechanical engineer (currently), I'm most excited to get involved in projects like Grid+

You're not reading the right books. Very few people need to know about buses and registers. Try reading some books about computers that are written for a general audience by journalists. Some examples:

• The Soul of a New Machine
  
• Hackers: Heroes of the Computer Revolution
  
• Dreaming in Code
  
• The Phoenix Project (this one's fiction)
  
  Hopefully they'll keep you engaged and you'll learn things in the process.

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

I'm in the same position as you, but I've added these to my reading list:

• The Internet of Money: A collection of talks by Andreas M. Antonopoulos, by Andreas M. Antonopoulos

• Some Blockchain Reading looks like a good reading list, mostly whitepapers

• Introducing Ethereum and Solidity: Foundations of Cryptocurrency and Blockchain Programming for Beginners, by Chris Dannen

Nice list! I'd add Debugging Teams to that list too. I love Five Dysfunctions and Manager's path

>How did you get started in DevOps?

I watched https://www.youtube.com/watch?v=LdOe18KhtT4. I realised this was the future and if you wanted to be in a high performing organisation you need to do what they're doing.

Unless you're in an organisation that is willing to undergo the cultural change of Operations and Development working together you're probably not going to go far. Creating a devops organisation from scratch is HARD unless everyone is on board.

Looking into the technology is the simple part, try reading around the movement. Pheonix Project (http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509) is a good start, from there I'd look into Continuous Integration and Continuous Delivery (https://www.amazon.co.uk/Continuous-Integration-Improving-Software-Signature/dp/0321336380 & https://www.amazon.co.uk/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912).

If by this point you don't know a programming language you're going to be in serious trouble. Learn something, be it Powershell (and honestly you probably will want to move onto C# if you want to be amazing at what you) or Python/Ruby.

Honestly you should be working towards what Google does with SRE if you want to be at the leading edge. https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X.

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

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

Yeah... but it's done by the writer of Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made. Each time he posts it's something worth reading, IMHO.

You should check out Jason Shreiers "Blood, Sweat, and Pixels." Recommended read for anyone interested in development.

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_apa_0m3eAbXMVFBFM

Yeah, I think it's pretty wild stuff. It just blows my mind that the biochemical network within a cell can be influenced by the emergent properties of the network itself (instead of any physical or chemical properties). The behavior of a network translates across applications - it's weird. Here's what got me into it - it's a pretty approachable read for the topic.

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

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

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

Definitely check out The Phoenix Project. I'm about halfway through it now and am really enjoying it!

http://www.amazon.com/gp/aw/d/0988262509/

Accelerate (book)


Planning methology

The 12 Factor App

Tooling: Go google for Continuous Delivery.

AWS Devops cert is not as useful as practical system design experience. Try other clouds as well, they are pretty good

Check out Blood, Sweat and Pixels for a bit of in depth info about the creation of The Witcher 3 and the seriously humble beginnings of CD Projekt. It has several other stories of games being made in a crunch period as well, it's a great read.

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

Edit:And I'm back

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

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

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

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

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

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

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

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

Introducing Solidity and Ethereum is alright. For now I would just look into the documentation of Solidity, Truffle, geth, Web3 etc. Mastering Ethereum looks super promising, as it's written by Gavin Wood (co-founder of Ethereum, made Solidity) as well as Andreas Antonopoulos (wrote Mastering Bitcoin). It's supposed to come out later this year.

The problem is that these tools change so fast that books might be outdated by the time you read or get them. It doesn't help that this is such a new field. Even the documentation sometimes isn't up to date.

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

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

The shit that gamers throw at devs on social media is unwarranted, transparency or none. Developers make games, and sometimes those games are good, sometimes they are bad, and sometimes it is or isn't their fault. Regardless, they still deserve to be treated like human beings.

Transparency is great; I love how Blizzard handles OW (that netcode video with the paper cups was awesome), and I think writing like Jason Schreier's Blood, Sweat, and Pixels are really cool and can help people understand the pressure and challenge of making any game, let alone a good one, but really, a lot of gamers need to grow the fuck up.

There's a really excellent book called Blood, Sweat, and Pixels that talks about development on a bunch of different games. If you don't know a lot about game development, it's a very eye-opening read. It's kind of amazing that anything ever gets released at all.

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

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

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

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

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

Excellent book for an introduction to what devops is all about. I worked at a devops consultancy for almost 3 years and we made everyone that joined read that book as well as the follow up, The Dev Ops handbook https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002

The devops handbook goes a little deeper into some of the technical ideas.

A phrase that you might be looking for is "rich get richer", or in mathematical literature, "preferential attachment processes". There's a very accessible pop-sci book about this:

http://www.amazon.com/Linked-Everything-Connected-Else-Means/dp/0452284392

Well, if you want to know the full story:

https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234

> Taking some of the most popular, bestselling recent games, Schreier immerses readers in the hellfire of the development process, whether it's RPG studio Bioware's challenge to beat an impossible schedule and overcome countless technical nightmares to build Dragon Age: Inquisition; indie developer Eric Barone's single-handed efforts to grow country-life RPG Stardew Valley from one man's vision into a multi-million-dollar franchise; or Bungie spinning out from their corporate overlords at Microsoft to create Destiny, a brand new universe that they hoped would become as iconic as Star Wars and Lord of the Rings—even as it nearly ripped their studio apart.

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

Very good read, also recommend the follow up DevOps Handbook:

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

It’s a shame that’s what you think.
I’d recommend you read this book. May help you understand what goes into and how games are made. 80 hour weeks, missed birthdays, no OT pay. It’s a miracle any game gets made.

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_OxCHAbH8FWXPM

This is a great (and short) introduction to what the DevOps mentality is. You and your boss should read it before you start hiring "DevOps Engineers".

http://www.amazon.com/gp/product/0988262509?keywords=devops%20books&qid=1457046991&ref_=sr_1_1&sr=8-1

It's not a "thing" but a philosophy on making sure Developers and Operations (SysAdmins) work together within your organization.

For a lighter read on graph theory try Linked: How Everything Is Connected to Everything Else and What It Means. It's a Gee-Wiz kind of book (i.e. light on theory but full of fun facts). And it's likely within your budget.

Good book to read that talks about stuff like this https://www.amazon.com/Start-Why-Leaders-Inspire-Everyone/dp/1591846447

Love the downvotes without comments... the assertion above is taken almost verbatum from a talk I went to where Gene Kim was presenting a couple of years ago.

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

​

Explained best in this book - The DevOps Handbook.

Your audible link takes me to a redirect and just shows the main page, is this the book you are referring to? Managed Services in a Month - Build a Successful It Service Business in 30 Days - 2nd Ed

This is a great book, you should get it.

And, if you're starting out, get Managed Services in a Month https://amzn.com/0981997856

Change control issues automatically make me think of Phoenix Project.

A great read for anybody in IT.

I’d also mention a great follow up would be the DevOps Handbook: https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002

Read the Phoenix Project this week. Seriously. It's a great parable for fixing your stuff. https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B078Y98RG8

I think you're looking for a book called "The Phoenix Project". It is based on The Goal but focuses on visualizing the IT value chain in a company as if it were a factory floor. It also gives a solid understanding of the role of DevOps in companies.

https://www.amazon.com/gp/product/1942788290/ref=dbs_a_def_rwt_bibl_vppi_i0

It's absolutely not in that category.

The language isn't obfuscated at all. This is an incredibly new technology, so everything is geared towards those who can contribute to the project. Much of the prerequisite knowledge is implied.

There is countless articles and videos that attempt to explain the platform though. If you are having trouble understanding what these terms mean, you can easily purchase a
book like this.

My ELI5 for smart-contracts would simply be, "You rent your bike to a friend. Using a smart-contract their payment is automatically enforced every week. The smart-contact could also respond to non-payment in a number of ways, such as automatically placing the bike on a rental marketplace".

Whether Etherium succeeds or not, some variation of smart-contracts are likely to be used by major institutions in the distant future.

Masters of Doom was a good read.

While not about video games, Dreaming in Code is close to the spirit of the wired article.

You'll believe in whatever you want to believe to ease the pain, it's ok to be angry it shows you care, doesnt make it relevant as a "critic" though.

You'll find all the common traits described in that article and this [one](
https://askagamedev.tumblr.com/post/126941182591/do-you-ever-feel-like-the-industry-is-too/amp)

Also may I sugest a little reading for the sake of context also

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

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

The Phoenix Project

> None of them seem to have any effect on the exchange of (legal) ideas or an attack on legal activities on the web.

The actions I listed redefined what was legal, so yes they had a huge effect.

It used to be legal to 'crack' computer games (because you owned them); software was even sold to do that (CopyIIPC). It was legal to reverse-engineer data formats that incorporated encryption/obfuscation code. It was legal to implement anything in software without fear of a patent suit (because software could not be patented).

Even the idea of 'unauthorized computer access' wasn't set in stone legally: Operation Sundevil was largely a prosecutorial failure.

The digital landscape changed so much between 1990 (when I got on) to now that it's largely unrecognizable. These things you think are reasonable actions were beyond the pale power grabs 20 years ago.

> Copyright belongs to the owner of the copy-written material, be it corporate or personal. I am a designer. Are you trying to say that my freelance designs are owned by corporations?

Before the DMCA, copyright offenses were a civil issue up to a reasonable dollar amount, i.e. no prosecutor would care about a few copied CDs but they might go after a counterfeit manufacturing ring; today you can be jailed for 20 tracks. Reverse engineering was strictly legal in all circumstances; today, foreign nationals who decode eBook formats can be apprehended at our airports on a layover. Used to be content could only be taken down if it was stored on machines that were themselves evidence for a criminal investigation; today it can be taken down with just an email from the right person (no judicial oversight). Perfectly legal material is now routinely pulled from the web just on the say so of a large corporate entity. Established musicians who have copyright to their own songs find songs on their own sites pulled by takedown notices from their label's parent organizations. This is what I mean.

EDIT: Forgot to respond to this:

> As far as the lack of expectation of privacy on the web is a given.

It didn't use to be. The idea of automatically scanning of all emails for interesting stuff was so far beyond what technology could do that Tsutomu Shimomura bragged about his ability to sample just the traffic at one mid-size ISP (Netcom) to find Kevin Mitnick's data, and he needed Netcom's admins to give him permission for it. No one had the CPU power to do it on a large scale, and every network was the jurisdiction of its admins. Today all traffic is routinely monitored and no one is asked for their permission.

In summary, some of the limitations were technical, some were legal, but the general thrust has always been more government power over the data flow and more restrictions on what exactly is 'legal', to the benefit of corporations over regular citizens. Not a knock on Obama, this is fully bipartisan. But 20 years after I got on the Net random strangers I chat with think this unprecedented level of information control is both normal and reasonable.

You should read his book, Blood Sweat and Pixels, it deep dives into a lot of games developments just like in this article (including Dragon Age Inquisition). It’s an absolutely fascinating, if sometimes depressing, read.

https://www.amazon.com/Blood-Sweat-Pixels-Triumphant-Turbulent/dp/0062651234

Similarly, Takedown is an interesting novel along the same lines. It's about the search for the legendary social engineer Kevin Mitnick and his arrest. It's non-fiction as well. The one caveat is that the novel is written from an highly biased point of view by a guy with a big ego, so that may turn you off.

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

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

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

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

They’ve done just that in The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by the same author as The Phoenix Project.

Have you tried the DevOps Handbook?
The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations https://www.amazon.co.uk/dp/1942788002/ref=cm_sw_r_cp_tai_WMs4ybAXM9TPX