catwind7

The presenter shared his written version of the talk and i'd say that this is probably this biggest takeaway:

> The important lesson is that you'll encounter multiple types of operators, with various mental models, and various approaches to your system. You must take a human-centric approach. Avoid the glass house, and provide well-layered observability probes that adapt to specific types of concerns, and provide both guidance and flexibility to operators. This will be the difference between a system where people can operate at various levels of experience, and a system where only wizards can thrive.

Is this mostly written for a sysadmin / dev-tool creators audience? As a web developer of consumer (non-technical users), while I found myself agreeing with a lot of these points, I feel as though this was not written with app devs in mind because I don't find the advice very actionable.

For example:

> your app should mostly expose operational data for its application users, not its developers.

Okay, so I agree that we should provide visibility through through _some_ means specific to operators at different levels of abstraction. i.e adding framework middleware logging (if you're building a framework for devs) for app developers so they don't have to add logging everywhere in their app hoping to spot something off.

What about the "end end" user - the 60 year old retiree using turbotax. I mean - those are also people feeding input into this complex system. What operational data do you offer them? Or are they not considered operators in this context? (I may have answered my own question haha)

Yeah totally. I have a friend who mostly works with the IT in big banks and pretty recently he told me he had to explain what "Git" was to a more senior eng. That was shocking to me but then again maybe I'm too steeped in webdev.

> Is the Web Dev job market in a good enough state

There's a lot of demand for devs across the board (this is my gut feeling from participating in hiring at my current company). This probably varies a lot across teams in a company, across companies in an industry, and across industries.

One strategy I recommend is to narrow down your target employer market so you can get more specific answers. What industries are you interested in? What are some companies you might want to work for? Do they have an engineering team (most likely). Then figure out what roles they have open and do your best to position yourself for those openings once yo u start interviewing.

> that I should risk more time and money?

What kind of self-learning have you already done? Can you give us some information about the courses / tutorials you've been following? Is this something you find yourself enjoying?

More details about your situation would help. For example, if you've mostly been following a coursera course for the last six months that's heavy on the theory side, I might recommend that you spend more time with something more hands on like building a web app to solve a problem you have.

My guess is that he's taking issue with this argument that I'm not quite sure was made:

"The market is flooded with people who cannot code, therefore it's easy to find a job as a junior engineer"

The market could in fact be flooded with people who cannot code (I don't know for sure). Assuming that's true, that doesn't necessarily mean it's easy to get a job as a junior dev (speaking from someone on the interviewing side).

I just want to thank you for your perspective.

I'd also add that "junior" can mean very different things for different companies. A junior engineer at Google could very well be "mid level" or even "senior" at a different company. Maybe even a CTO at a startup.

The industry is still relatively new and I think we're still in the early stages of grappling with how to best match programming expertise with company needs.

Whether or not programming can be completely automated is an interesting question.. when I think about what would make it unecessary for a human to be specifying the behavior of a computational system the only phrase that comes to mind is "general ai".

That end to end tests for critical business functions will save your ass the moment you, your team, or your test suite fails to spot a bug.

I once added a line of code that did not execute in test environments because it involved a request to hosts that were only available on staging and production. So the tests were obviously fine but shit went south in production.

Not true.

http://money.cnn.com/2017/02/02/technology/elon-musk-trump-t...

https://www.theguardian.com/technology/2017/feb/07/elon-musk...