Freenome | South San Francisco, CA | Senior Engineers, ML Engineers, Bioinformatics, DevOps | Onsite | https://www.freenome.com/careers
Freenome is an AI genomics company on a mission to empower everyone with the tools they need to detect, treat, and ultimately prevent their diseases. By applying advanced machine learning techniques to recent breakthroughs in genomic science, Freenome is developing simple blood tests to detect early-stage cancer and make treatments more effective.
The Engineering team is responsible for the heart of Freenome - the genomic data, its (anonymized) patient-related metadata, the genomic pipeline, and the Machine Learning platform for running experiments. We run a Postgres/Python 3/React stack on Google Cloud via Docker/Kubernetes. We're a small team looking to expand to nearly 30 by the end of the year, so now's a great time to come for growth opportunities - growing teams around you, working on cutting-edge platforms for pipelines and ML!
I think this attitude results in people only ever reaching local maxima in their development environments.
Adopting something like Haskell instead of Ruby isn't just an exercise for magpies who like new shiny things (In fact, Haskell is older than Ruby, and many concepts in functional programming are far older than most OO design patterns). It's embracing a different way to think about programming which can have fundamental improvements to the maintainability of the code you write, rather than just cursory ones.
No one is saying that a business problem can't be solved, or money can't be made, using Ruby.
Sure, rewriting a project from one language to another is very expensive and usually not worth it, but does that mean that we shouldn't explore other tools at all? At some point, a new project will begin, and it'll be valuable to have a more robust decision about which tools to use than just "Rails worked ok for us last time."
I'm not saying you can't ever move on, just do it with dignity.
That is to say, picking products mature enough for production use, and executing your migration without feeling the need to justify it to the world by shitting all over your old environment.
Age has little to do with it. FWIW, Haskell is trendy right now. Probably for good reason. My issue isn't with the direction, it's the method.
When you switch to something different, you see that a bunch of your problems and annoyances simply went away. You may not see yet the new problems and annoyances that you acquired. You're in the honeymoon phase.
With time, you will see the problems with the new language/tool/environment. Is it better than what you had before? Maybe, maybe not. But you are not in a position to accurately evaluate it while you're in the honeymoon phase.
I attended App Academy nearly 3 years ago. I'm currently a software engineer at Airbnb. I haven't kept in touch with everyone from my cohort, but I know some of them are working at Lyft, Uber, Google, Slack, and 23andMe.
I've never understood the whole "Don't use Redux until you need it" idea. If you're building anything larger than a toy app, component state isn't gonna cut it, so you're better off structuring your app with Redux or MobX or something from the start than rewriting stuff to include it later.
There's a difference between "don't try to learn Redux until you understand React", and "don't use Redux right away when you start building an app".
For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline.
Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
Honestly many developers don't have freedom to experiment with new things on their own. I got web project, I'm thinking, well, it's a good time to try out React, I've heard it's cool. I'm convincing my manager, if necessary and I'm starting to build production project without any prior React or Redux or whatever knowledge. I'm not going to do it step by step, no. I'm grabbing everything and trying to bundle it all together. I know, that my app will need state, so I'm using Redux. I know, that my app will need routing, so I'm using router. And my experience is similar to author's, I had a lot of troubles to even get build setup working. I guess, it's more about javascript development tools, not specifically about React, but point stands still. And if I'm understanding, that I just got buried under pile of things, I'll throw it out, rewrite everything on Angular I know and love and forget about it for a few years, until it matures and I could try it again, hopefully with less troubles.
If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
I'd recommend pitching it to your manager as a one week spike, and if that goes well do a presentation on it and sell technical leadership on it from what you learned. Then you can add proper tooling. Make a few trade offs to save time as needed. That strategy worked for me.
Great advice, and well articulated. I'd add that if someone is coming from angular 1 or even has just built numerous single page apps, they will immediately see the benefit of a single source of truth client side data model.
I really love Redux, and I use it for most things, but that is simply not true. Redux/MobX is a solution to the Angular 1-style issue where state is all over the place, but you sure can make full blown apps that way (it's not even a full solution, but rather a different set of tradeoffs...which is why a lot of people start using Redux then start pushing back in the other direction and you end up with a mess).
And even if you want to centralize state, with local state it's not even that hard to do yourself (put it at the top or in a few small containers, push everything down, have callbacks that bubble it back up. A bit verbose, but easy to abstract out, though you'll end up with something close to redux).
The main issue with all of this is that 95% of the stuff you read about all of it on the internet is wrong, namely because building a real app and maintaining it is very different from making a toy project or a Silicon Valley style MVP in 6 months. People optimize for the later, then when they start maintaining their app its shit. So all the info on the net helping you to reduce boilerplate, optimize for the first version, etc, is just hurting you (but its almost everything you find online)
For a simple CRUD application, there's not much wrong with just passing state down from a parent component. Eventually you end up abstracting and automating it; they're values, like everything else you program with.
Abramov has been beating this drum for a long time: there really are a lot of React apps that use Redux but really don't gain anything from it.
It's entirely possible I don't know what I'm missing and/or my React usage so far mostly falls in the "toy" scale, but I've not yet felt a need for Redux or another state management system. Our strategy so far involves very little use of component state (nearly all usage is for form fields and showing/hiding modals). Everything else is in the props, and all 'app state' lives in a collection of modules that get DI'd into the components via their props. It seems like it's probably not too far from what Redux is going for at a conceptual level, but so far it's worked well and been easy to work with.
We also use TypeScript though, so this more OO-style approach felt more natural. It's not particularly verbose (in the context of interfaces and static types, so YMMV) and it's been extremely easy to work with so far.
I don't quite understand it either. React and Redux play nicely with each other but they are completely orthogonal. You can use one without the other, and I've seen Angular 2 developers use Redux to great effect. As Dan himself admits, Redux is inspired by Elm architecture and I personally find this approach extremely elegant. I admit it is demanding but it also forces you to put more effort into designing your application which in my experience is generally a good thing.
Yes and no -- you could also get away with passing the state down from a higher-level component. This does break down quickly, but if your app isn't too complicated, it can be enough for the first version. (Certainly, if I was unfamiliar with React, I would try this before integrating another library like Redux.)
Freenome is an AI genomics company on a mission to empower everyone with the tools they need to detect, treat, and ultimately prevent their diseases. By applying advanced machine learning techniques to recent breakthroughs in genomic science, Freenome is developing simple blood tests to detect early-stage cancer and make treatments more effective.
The Engineering team is responsible for the heart of Freenome - the genomic data, its (anonymized) patient-related metadata, the genomic pipeline, and the Machine Learning platform for running experiments. We run a Postgres/Python 3/React stack on Google Cloud via Docker/Kubernetes. We're a small team looking to expand to nearly 30 by the end of the year, so now's a great time to come for growth opportunities - growing teams around you, working on cutting-edge platforms for pipelines and ML!