The more you know broadly, the smarter you’ll sound. And generally, you will tend to be more useful and fulfilled.
If you want a career that is focused, you have to choose a focus. I’ve struggled with that. You need a broad base of knowledge to be good at understanding all things, and how they connect.
But eventually someone needs a lightbulb changed, and I’m testing the grounding of a nearby lightswitch while on the phone with a contractor about shielding noise from the antiquated home stereo system.
Edit: I should probably mention explicitly.
Investing in TensorFlow or CUDA is one thing. Investing in certain ML techniques or modeling domains another—and python yet another—
Systems and general engineering is a completely messier enchilada. You still get paid!
So. I guess. Do better than I. Choose a scale. It’s impossible to focus on everything unless that’s just an impulse you’ve got :)
But strike where the iron is hot.
Right now the future is ML, not learning the intricacies of the 2022 tech stack.
Heck, I’m an automation enthusiast, but if that’s my only trick and I’m good at it, I’m out of work like next week ;)
Any company with a rigorous approach to product development or even SRE will rely heavily on metrics. The ability to create, maintain, monitor, transform, understand and reason about those metrics is invaluable. To decide what to work on and the quantify your contribution, the ability to effectively run experiments is invaluable. This will naturally fit into a structured product management cycle.
This will be a way more natural fit than, say, "purer" software development (eg writing device drivers).
So much of successful software engineering is not just how to do something but deciding what to do (and not do).
Maybe a 60/40 mix is optimal
I think it's worth seeing how far you can get with this approach before interviewing for engineering roles at other companies.
One notable caveat with my approach: pursuing a portfolio approach took me a whole year to switch from DS to engineering. As you point out, grinding leetcode may only require half that time.
MY LEAD: Uhhhh... What if it was two weeks long, tops? Or even less?
MY ASSIGNED HR PERSON: Great, let's process your leave of absence! We'll cut your benefits and convert your stock options so you'll have to buy them out a lot sooner than you were prepared to!
The real goal of a bootcamp though (besides networking) is adding a project to your portfolio. You can then show off this project to hiring managers to demonstrate your competence.
You don't need to do a full-time bootcamp to make this happen! I just checked and Flatiron school and Hack Reactor both have online part-time full-stack bootcamps. Also, while not as big of an investment, online platforms like Codecademy have career paths with a capstone project you can complete and add to your portfolio.
So, overall there are a variety of pathways to do this. Totally fair to point out though a bootcamp of some kind is a nice option in the off-chance it's a possibility.
Curious if anyone else has switched from data science to software engineering, or has thoughts on comparing the two as a career choice. I'm all ears!
One thing I don't think gets talked about enough: How much time analysts spend doing analysis vs. time spent dealing with data quality/architecture/process. So much analyst time is lost in the latter, which I think contributes greatly to burnout. But the growing intersection with engineering has and will continue to address this, albeit slowly.
Training and tweaking models looks like the easy part of developing data driven products. Hiring compenent enough people also seems easier than for software engineers.
Many ML libraries produce good enough results without having to design elobare models myself. I see data science more as yet another tool in the belt of a a software engineer - like server admin, CI/CD, IaC, databases,...
Here's an earlier draft of the post on Quip: https://gstudent.quip.com/ILF1ABpvjsSh/Can-a-Data-Scientist-...
Some countries (Canada I think being one?) may require you be licensed/registered with an engineering body before you're allowed to call yourself an engineer, but thats not the case in most countries AFAIK
Then I started working for an American company that was like shrug no laws against that.
I just can’t say professional engineer.
The whole thing makes a ton of sense when we’re building bridges or airplane safety rated computer systems, but not so much when building websites or whatnot.
Let the downvotes commence.
Edit: This is a gentle ribbing, but there really does seem to be a different approach in the philosophy of how to solve a problem. Engineers seem to eschew abstraction while software folks embrace is (sometimes to a fault). It's actually pretty fascinating.
Actually this is one thing that has always confused me about “software engineers,” at least as someone with an engineering education who isn’t doing engineering work really: we learned how to do particular types of problems very well and reliably, and generally learned a bunch of math tricks. But at a fundamental level the material that the physics students were learning was basically more complicated. Scientist has always felt like a more prestigious title to me. Since most programmers have computer science degrees, why don’t we call ourselves computer scientists?
Of course, you can do too much abstraction.
On a spectrum, there are software developers that follow the engineering design process and use all sorts of knowledge of applied science, but there are also those who make it all up as they go along and rediscover or rename concepts independently. Each approach comes with its own associated benefits and tradeoffs, and there are times and places where the latter end of the spectrum can be desirable.
At least that's my hot take.
[1] https://www.mcgill.ca/engineeringdesign/step-step-design-pro...
Examples: measuring data scale for growth rate and future needs, calculating incremental costs of cloud instances and data stores, designing and proving a state machine, instrumenting systems, measuring and stress testing a system against load, understanding back pressure and dynamical behaviors of distributed systems, designing threaded or active/active systems, vector clocks, consensus algoritms, test suites, etc. etc.
I've had to write short inductive proofs in several of the systems I've built.
It's engineering. The sooner we get over the imposter syndrome debate of what we can and cannot call ourselves and embrace the full scope and possibilty of what we can achieve, the sooner we can become better and more capable software engineers.
In what context was this necessary?
