For Money: Not necessarily any more satisfying or churn-proof than web development; But definitely more lucrative. Salesforce/SAP/Oracle consultant, mobile app developer, SEO or becoming a web dev consultant or remote work arbitrage or just becoming a manager.
For Domain Knowledge, you are becoming a computational {Biologist, Geologist, Financial Quant} than a pure coder. Fields like modeling fluid dynamics or finite element analysis for GE or GM; or modeling petroleum reserve for Shell; or Bioinformatics for BigPharma or modeling risk for banks. You probably have to go back to school for another degree in that subject or get the equivalent on-the-job training.
For Technical Skills, you are specializing in a sub-field of practical coding/IT, working at a software company. Like Data Science/Machine-Learning (distributed computing tools and knowledge about basic learning models), or Information Security (e.g., MITRE) or Embedded System (C++/Assembly) or high-performance system (e.g., Akamai; C++/networking).
Curious anyone who took the step to specialize or just started out in a more specialized field and their thoughts; and if I am missing any potential specialization options out!
https://github.com/dlang/dmd/pull/6176
(Yes I know some other compilers do that already.)
It's fun knowing how it all works from the source code to the executable.
I agree that it seems that programming + X is often a much more powerful combination than programming or X alone. But I would say to anyone starting out that it is better to head towards, and get the formal qualifications for X, and learn programming on the side (or if in college, get the major in X and a minor in CS).
The reasons are that programming is relatively easy to learn outside of classes, and programming itself really doesn't require formal qualifications.
For me, biology has been orders of magnitude harder to learn than coding. With coding, you can learn by doing, and you get immediate feedback from the compiler/interpreter. Not so with biology. You can be mistaken for weeks/months/years and never realize it until you read just the right article. And often, domain-specific knowledge like biology seems to be composed of thousands of tiny details without too many general principles, whereas if you learn a few basic principles for programming, you can learn pretty much any new language or framework easily.
I don't know if this is generally true of all specializations, but if so, it would behoove someone to get started on learning the specialization-related information ASAP, because that will take much longer to reach proficiency than for programming.
Is it the statistics (finding the right statistics inference test and knowing what are the pitfalls of your models)? Or is it understanding the underpinnings of the biology behind a particular pathway you're studying? (e.g., knowing how to perform or iterate on the wet lab experiments of doing in-vivo or in-vitro experiments). Thanks again for your comments.
Yes, this is it. You are right that the really general basic concepts (what is DNA? how does transcription work?) are not all that hard to learn. And it is certainly part of the core job skills to know, e.g., how to process sequencing data and how to use statistics. But in the real world, bioinformaticians work in collaboration with wet-lab biologists.
So, a typical project for me might look like this: collaborator comes in and tells me that his lab studies a particular protein X that operates at the presynaptic terminal in neurons. And they are collecting data about how some perturbation to X affects other cellular systems. The data will often be some combination of sequencing/array data and more specific wet-lab experiments (western blots, electrophysiology, etc).
So, in that case, to really do my job well, I have to go back and read in depth about the presynaptic interface, the major proteins and the mechanisms that work there. I may already know the generalities, but to really be able to interpret the data correctly, I need to know the details.
Now, imagine doing this process 10-20X a year for different collaborations and totally different biological systems. It's very hard to keep up. Now, it is certainly possible to be the kind of bioinformatician who is "give me your sequencing data and I'll give you the DE genes back", treating everything as a purely technical problem. But these kinds of bioinformaticians are not as much sought after because the wet-lab biologist doesn't want Excel spreadsheets full of lists, they really want to know "what do my results mean?". And to answer that really requires both the bioinformatician and the wet-lab biologist to understand what the other is doing at a more than superficial level.
In short, the hard part isn't learning the things that are used in every project, the hard part is learning the domain-specific information that is relevant to each individual project.
Heh, I feel that way and I'm 22. Unfortunately the only language I know is JavaScript and the stuff I am interested in and learning isn't quite there yet in terms of jobs.
>the other reason is because it's easy/boring as hell
I legitimately think front end development is not only very fun, it can have some really challenging aspects. I wouldn't think there's any programming challenge that is inherently easier because it's on web as opposed to something else.
Of course I bet there are domain-specific tasks (Distributed Programming, Embedded hardware to list some) that are likely harder than web development. But I guess what I'm trying to say is: I don't appreciate you calling what I make a living off, and spend quite a few hours studying weekly 'easy/boring as hell'.
Developing a good UI is difficult, no question about it, but not for technical reasons. Whether you resent that or not doesn't make it any less true.
>I wouldn't think there's any programming challenge that is inherently easier because it's on web as opposed to something else.
Not because it's on the web, because front end work doesn't require anything more than knowledge of your toolset and some design sense.
It's nearly all "hey, build a UI with some CRUD functionality which is essentially the same as the 100 you've built before, but for this special snowflake customer." Bleh.
I imagine it's fairly similar at Facebook.
http://www.anthonyhall.org/c_by_c_secure_system.pdf
http://www.methode-b.com/wp-content/uploads/sites/7/dl/thier...
https://ts.data61.csiro.au/publications/nictaabstracts/7371....
But from time to time one of us monkeys gets lucky and changes the world.
So I guess it's a risk/reward thing :)
The original poster said nothing about frontend vs. backend. Still, you're absolutely correct, backend work is mostly gluing together pre-built libraries and software too.
oh boy, you are so wrong! as an old fart having spent a number of years building UIs, can tell you, this is hard! information layout, controls, flow - it can be tangled into a total CF, or it can be seamless. you are not pasting libs on top of libs - that is the job of a monkey, front or back end alike. normal devs start their day with talking to end users and listening to their pain. then they spend rest of the day trying to alleviate it. monkeys spend their days thinking how they can add to user's pain by pasting more layers of crap.
engineering is an important part in back end, front end or in cleaning the toilets. it is not what you do, it is how you do it.
Think; designing the CV systems for self driving cars (since that's a hot topic at the moment) vs designing a UI which works seamlessly across browsers. One is a real, honest to God engineering challenge; the other is an exercise is patience and perseverance. There are many more people in this world who could pull off the latter than could the former.
If you truly, honestly believe that UI dev work is technically difficult when measured against the rest of the engineering world then I can't imagine you've been solving hard problems throughout your career. UI layout is not "hard" and it's certainly not engineering, nor is 'cleaning toilets'. of course creating UI's comes with its own set of challenges, but I'm specifically talking about technical difficulty.
> your contempt for people who build UI
You've carved out your own definition of Frontend dev, it doesn't always require business/domain knowledge, many just put stuff on the screen.
Incidentally, I found this hard - not in a math problem way, but in a costing a lot of time and patience way. I distinctly recall spending a couple of hours trying to align some div after being requested to do so. I strongly dislike CSS.
Most of the individuals making CV demos are not making unfathomable genius-level demos: they are taking an existing library and bolting on a simple application to it. And most such demos are flimsy and not commercially viable, because the technology needs more massaging at a deeper level than the author is capable of in order to fulfill the desired marketing promise.
Meanwhile, simple bolt-on UI tends to be good enough. Not because it's fine as-is, but because the user can accommodate for its brokenness without being able to express what exactly is wrong with it. The product can ship and create value, albeit not as much. Yet, a UI dev who wants the best possible experience has to have the same attention to detail up and down the stack as the CV dev who wants their algorithm to perform well along every metric. UI innovations are understated because they oft seem obvious or unsurprising in retrospect, but they do come along every so often, and often in tandem with the developments elsewhere - these days, AI algorithms are increasingly intertwined with the interface in a very direct fashion, when one considers voice processing, predictive text, or other such features.
And yet, if you should aim to achieve better UI, some naysayer will come along and proclaim that you have made something "overengineered" and should "just use a standard toolkit like the rest of us."
What, in your mind, makes an engineering problem hard? I've certainly had to dig out CS algorithms and 'clever' applications thereof to reach desirable performance out of some custom widgets in front end projects. I don't know if that can considered hard – hindsight tends to make everything seem easy – but it is certainly beyond pasting in a library like you describe.
I have to agree that you can create some very useful projects that do not deviate from a framework/library's documentation, or what have you. But we don't really know what the parent in particular is working on.
A problem which requires a high degree of creativity, intelligence, and technical ability, likely one which hasn't been solved before. You're right; it's a bit difficult (at least for me) to define, but we know it when we see it. Sending men to the moon was a hard engineering problem; implementing the UI for gmail was not.
You speak of using 'CS algorithms' in your UI's. I assume you're talking about things like optimizing a search of a list by using a better data structure or sorting algorithm. C'mon. You didn't solve these problems, other people did, you just did a little research, and this is basic stuff most of us can pull off fairly easily.
The vast majority of web development is not engineering. It is in fact just pasting together code other people wrote to solve a particular, relatively trivial problem.
Let's be real, for a moment. By your definition of a hard engineering problem, very few people are spending their time doing it. Virtually no one is doing it every day.
Why pick on front end dev specifically? You think the average backend dev building installing flask is facing a lot of unsolved problems? You think the average game dev is rendering 3D models in some new, magical way?
We just released a prognostic test for colon cancer which is actually relatively groundbreaking as it provides a new treatment path for people who previously had no options.
So yes, I feel that I am. I have been a part of small engineering teams delivering brand new technologies to the market my entire career.
And you're right, very few people, especially in software, are solving hard problems. I wasn't picking on anyone, I was responding to a comment.
So you are implementing some vision library. How is that a hard engineering problem?
> So yes, I feel that I am.
That's the crux of the issue. You are doing exactly what you find so distasteful about web development: implementing existing algorithms to solve a specific problem.
Unless of course, your team is actually inventing new vision algorithms that somehow changed the field, which I'd love to see the paper on.
By saying that "we know it when we see it", you are acknowledging that this is a value judgment (nothing wrong with that, just don't present it as an absolute truth). Also, by your definition, sending humans to the moon is not a hard engineering problem. It has been done before; it involves pasting together some relatively well-understood components like rocket engines and guidance systems.
that's a high bar for engineering. Integrating known solutions into a situation is engineers. Mechanical engineers don't discover the laws of motion themselves.
You assume wrong. They were not straight up textbook problems, but I agree that I used a wealth of existing knowledge to apply it to my specific problems. That's what engineering is.
> You didn't solve these problems, other people did
Naturally. If you are working on finding novel discoveries the world has never seen before, you would be appropriately labeled a scientist working on science. Hence, also why we consider the algorithms I mentioned before to come from computer science, not software engineering.
You're looking at this backwards. It isn't about the task. It's about the person who approaches the task. Someone "creative, intelligent and technically able" (to quote your later comment) will bring vision to any task.
Like water they will find their level, find the new and shining thing they can bring to the arena in which they find themselves.
These invidious distinctions contribute nothing to mutual understanding amongst computing professionals. All of whom need to work with each other to achieve great things. That includes the documentation people - shout out to them for their intelligence and creativity too.
I have the distinct sense that you might not have done much of this.
There might not be many esoteric algorithms to implement, but there is plenty - more than plenty - to do in terms of managing UI state and back end integration, especially if you have stakeholders who want to see a variety of complex UI manipulations happening in response to various business rules. Which can often be internally self-contradictory. In a DOM that delights in being uncooperative, pretty much . . . always.
Frankly, it's enough to make using Java or a C variant for typical back end work look like a walk in the park.
At some point you realize that it's a race to write more lines of code with every iteration, and that employers will gladly abuse your passion in many ways go get cheaper output from you.
If I may take the liberty to give you an advice here, go for the lower level/more specialized stuff as your career progresses. Not only they change at a slower pace but they are paid way 2-4 times more here in Toronto. If you care that you studied and make a living off of it, try to focus after technologies where your hard work will be relevant longer.
As for me, I love what I'm doing. Currently it's a mashup of crosplatform c++14, .net core rest api, elastic search, postgre and bunch of connecting glue. Our resident js expert is busy for the next few weeks so I'll probably learn typescript and go up my stack to provide an interface.
Smaller shops are tons of fun.
This is my own strategy, though domain specialised rather than low-level.
I don't want to do "business" or project manage.
Working on the backend building APIs, optimizing data flows and managing backend services is more fun, and wildly more productive, if less whizz-bang and shiny.
Speaking as a 20-something who frequently forgets he's not a forty-something...
I think this is the issue, it's not that the problems aren't hard, rather you aren't solving new problems, but trying to figure out how the existing tangle of software can be made to do what you want...
We created a universal interface for computing, and it is web programming. It does not matter if you are creating a CRUD application of an improved Google search, you'll have to present it the same way. Thus, unless you are willing to give up control on the presentation of your work, you'd better learn it.
Web Dev is just so easy to get, and pays well, at the moment the temptation is hard to ignore.
Virtualization as a way of controlling specific application environments has been around for decades. The current movement (kicked off by the hypervisor work over a decade ago) is towards running more virtualized environments now that hardware and software support is much better (reduced overhead associated with it, greater portability).
Do you mean that they're overused or that their value is overstated?
We will see if Docker and other container technologies will get their hold in industries other than startups. For now, all the people who use it that I see are the cool kids on the block in their hoodies. I think boring technology is good technology in that it provides value and stability for everyone. I am yet to hear of one Docker adoption where at scale the company saved more than a three digit sum year-on-year. Remember that you also pay an extra for sysops folks who run these things, and they will ask a higher price because the tech is hip!
For me, I'll stick to VmWare and kvm for now.
Those very same companies offer remote work increasingly, as they struggle to find talent in the aforementioned field.