cowanon22

> I bought a new Nissan Kicks last year (the lowest-end crossover SUV) and it seems pretty dumb.

Not sure about 2020, but 2021 has Automatic breaking, pedestrian detection, and collision detection standard. There are likely a few hundred thousand to millions lines of code in these various systems. Even "dumb" cars today have tons of software, it's just hidden since it doesn't require user input. Literally every aspect of your driving is fully computerized - braking, acceleration, engine spark plug ignition, transmission, steering, etc. The infotainment is often relatively simple compared to all of the other software running internally.

BTW, If you find that nothing is of interest to you, then you may be suffering from depression which can often happen after severe burnout. I would recommend seeking out some help if that is the case - there is no need to suffer in silence!

I have also suffered periods of technical burnout -- it's almost inevitable that the workload will exceed your capacity at some point in your career.

Contrarian opinion here - maybe it's okay to leave the side projects behind. I don't work for a FAANG, but have had several senior and lead developer positions at mid-to-large companies for the last 20 years. As I moved in my career I took on increasingly challenging projects at my day job, and quite frankly there was nothing I could do in my free time that would be close to the challenge or variety of some of the larger projects I have worked on. By the end of the week I just had no brain capacity for more tech stuff.

I have consistently spent 10% of my work time on new training (whether it was company policy or not) to ensure that my skills have kept up to date, and I use that to introduce new technologies to the company when it organically fit the companies needs.

I would suggest experimenting with some new hobbies (preferably something athletic to offset the office work) to see if anything interests you. You may have reached the point in your career where your day job is enough "tech stuff".

>Refinement certainly helps but Toyotas are reliable because any car would be reliable in the hands of Toyota owners.

This has not been my experience. Toyotas are just better built coming out of the factory. In the past I've had newish Chevy, Ford, and Nissan cars, and after about 30-50k miles each of them started having various small noises/rattles that built over time until something failed. The Toyota is just smoother overall out of the factory, and parts wear out more slowly.

Personally, I would hire a lawyer in the relevant jurisdiction and specialty. Laws are complicated, and collections and court cases are very expensive if you happen to be wrong. The lawyer can help you reduce the amount if you happen to be responsible for part of it. The "magic words" will have much more power if they come from an practicing attorney.

There are high quality workers everywhere in the world, but they are also expensive. You generally get what you pay for - the skilled developers in others countries are also smart enough to find a better deal if they are underpaid. The 1/3 price workers are not at the same level, and quite frankly often overpaid compared to their relative productivity.

I think Steve jobs was mainly looking at the cost vs potential profits of Opendoc. There was a lot of ongoing engineering money going into development, and the potential revenue streams seemed too niche for the amount of effort. From his perspective it was better to move the talent to more strategic projects that matched his 5-10 year vision. He wanted to pivot to chasing end users, not to expanding the existing developer base. In the long run it worked, with a lot of short term pain.

If you truly want to learn computer science from the basics, I would recommend starting with Nand to Tetris https://www.nand2tetris.org/ and the corresponding book and labs (and Coursera courses), along with Code the hidden language... They cover how a computer is actually build from first principles. After this, Structure and Interoperation of Computer Programs and the Algorithm Design Manual.

Unfortunately most roads lead to management in tech. Tech knowledge is a decaying asset with a half life of 5-7 years. Eventually, you have 10-15 years of experience and your skills are decaying as fast as you can learn new ones. You look up and realize you are the oldest person on your team still writing code. Suddenly you fit in more with the other managers than with the developers. Such is life at most companies.

I think the book "Fundamentals of Software Architecture, an Engineering Approach" (Oreilly) is much closer to what most engineers need today than the GoF book. It covers topics such as layers, pipelines, microkernels, events, microservices, components, and how to put it all together into a coherent design.

GoF was great for it's time and context, but the world has moved on and even mid-level engineers need to be aware of software architecture and how to put it all together.

I agree with this - young engineers typically do not appreciate the importance of building the right thing vs building it well. However, the OPs point stands. McKinsey and these other companies just regurgitate what is printed in the trade press and charge you top dollars for it. You meet an experienced person once at project kickoff, and then most of your contacts are fresh grads with 2-5 years of experience. They really specialize in attending meetings and conference calls, but are all over the place (from excellent to awful) at actually implementing things.

> are not actually data scientists, at best they are data analysts.

Unfortunately the phrase's usage has been corrupted by HR departments, and the BA types of job listings now outnumber the "real data scientist" listings.

My background: I am a tech architect/manager on IoT projects who designs and helps develop analytics systems. I do some basic data modeling in my role, but defer to experts to build a better model once we find some area of interest.

The actual skills of light programming (R, Python), data literacy/manipulation and some basic modeling (statistical/machine learning, Bayesian methods, time series, etc) are useful for many job roles, and I think will be considered basic skills for college graduates in the near future. This isn't new - operations research, particularly Six Sigma and quality control, have used statistics and some light programming to solve business problems for decades.

By itself, I don't see Data Science evolving the way promised by schools and boot camps. Most of the positions named "Data Scientist" (at non-tech companies) are really just senior business analysts; I work with a group of them at my company and 90% of their day to day is just extracting and analyzing various reports for other managers and directors. When an interesting (and potentially lucrative) business problem does come along, they usually outsource to a specialized analytics firm and the data scientist helps coordinate that project. (If you have a good data dictionary, a clear outcome in mind, and some basic knowledge of the field it's relatively easy to outsource the advanced work.)

st1x7 had the best advice below -- learn the basic methods and then apply them to your field. If you google "agriculture iot research papers" you'll find tons of examples of people using sensors for data collection and then analyzing the data to improve some process.

TL;DR I see Data Science melting into other roles, but the basic skills/data literacy are useful for almost everyone.