I became a software engineer after 5 years in data science
zachary-thomas.medium.com
zachary-thomas.medium.com
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
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.
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.
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-...
There is overlap, but they are not identical skillsets.
Analysts are certainly developers, but engineering involves more of a sense of scalability, analysis can do this, but it is generally more granular.
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.
https://ncees.org/ncees-discontinuing-pe-software-engineerin...
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?
What I think are the relevant extracts from the article:
> “Do you consider software engineering actually engineering?”
> Of the 17 crossovers I talked to, 15 said yes.
> That said, many of the crossovers [3] also added an additional qualification: software engineering is real engineering, but a lot of people who write software aren’t doing software engineering. This is not a problem with them, rather a problem with our field: we don’t have a rich enough vocabulary to talk about what these developers do.
The engineering field has developed a vocabulary for different professionals in the field. Why can't this be applied to the software field since it is a form of engineering? There are engineers, technologists, technicians, and trades (at least where I am). The issue is there are education and work experience requirements that lead to licensing, which people will say are inequitable and gatekeeping [4]. From 2, there was an experience-only path available to get software engineering licensure, so if the field really wants it, there seems to be precedent to allow for alternative routes into those titles.
[1] https://ncees.org/engineering/pe/software/
[2] https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
[3] The definition of "crossovers:" "people who used to be professional engineers and then became professional software developers. I call these people crossovers, hybrids between the two worlds."
[4] I'm sympathetic to these concerns. I studied engineering technology and worked as a technologist at the beginning of my career. I wanted to become a mechanical engineer, but I couldn't afford to return to school full time to complete the remaining 2 years for the BEng. (My school offered a 2 year diploma for engineering technologists, which led directly to years 3 and 4 year of the BEng.) When I wanted to complete the degree, a full time course load was required (7 courses per term at my school) for the engineering program to maintain accreditation.
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...
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.
Of course, you can do too much abstraction.
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?
Because they aren’t doing scientific research, they are applying the products of such research to design (and build; with software the distinction is less significant than with many physical items) products, so its somewhere between architecture/engineering and constructiom, rather than science.