Location: Manila, Philippines
Remote: Yes
Willing to relocate: Yes
Technologies: Fullstack Javascript; NodeJS, React/Native
Resume/CV: Available upon request; LinkedIn can be provided as well
Email: hi@meeco.dev
One particular use case that I might try this for is for (very) restrictive environments. One such case was with my previous work where we had to develop services for the client but we can only do it in a remote desktop with certain network and application restrictions. Instead of having conditions for the environment to load certain config, we can simply retrieve the secrets stored in AWS (ex. RDS credentials) via the agent.
It really should not happen, especially for fully remote teams and/or companies.
Current company has built a comprehensive career management that encompasses even remote workers. It's a very objective and simple approach. The challenge comes with crafting KPIs with each employee as basis for promotions, but so far it has been paying off.
jQuery changed the game for frontend web development. Instead of static pages on the browser, interactivity for the client-side proliferated because DX on top of jQuery was way better. Then they started cursing jQuery for its limitations.
Then came React -- which again changed the game for frontend web development. Instead of wonky scripts and targetting CSS classes, you get a modular and reactive approach in building the web. Then they started cursing React because of performance issues and implementation complexities.
Svelte was designed to behave like React but perform better and reduce the implementation complexities. I had the chance to work with Svelte 1 back then and as a React developer, it would really make you think "Why did React do that?".
This is probably on top of HN because people loved Svelte too -- but some followers are now questioning the direction as this change is gravitating towards solutions that React already implemented. As it happens, React did solve a lot of problems for the frontend, and they really nailed it.
I disagree employers don't have a win on the remote work setup. For one, they can reduce a lot of overhead for the upkeep of physical offices. There's also giving the idea of giving the employee more time for themselves, when in truth they really actually extended his work hours; just at the comfort of their homes and at their own pace. While it's not perfect for everyone, remote work has its perks for both employees AND employers.
More time often isn't really what the employer wants. I knew someone who put in a lot of hours, but always in the afternoon / evening -- when everyone else already went home. Which sucks for everyone who needs to coordinate with them, because you always need to wait a day for them to get back to your emails...
>Make yourself valuable to negotiate better terms, or look for something better
I could not agree more. You would always have leverage with salary negotiations during interviews if you can justify the value you bring on the table. For technical positions, unless the hiring process does not involve any technical assessment, it's quite easy to spot who knows what they're doing from those who are just good on paper.
Specialized technical people often look down on supposed fullstack engineers because specialized technical people value mastery over familiarity -- something a lot of FS engineers really try to be exaggeratingly proud of. While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner.
Managers are excited about FS engineers simply because if they scoop up good ones, those who really know what they're doing -- masters of several areas of their stack -- they can rotate them effectively at a fraction of a cost, if not for free.
> While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner.
I fully disagree with that. Great software isn't just about what stack you have mastered, great software is build by people who can do whatever it takes to build great software, and that's not necessarily just about your stack.
That's funny, because as a generalist I tend to look down on single-purpose developers. Way too often they don't know anything about the rest of the system they're interfacing with and produce locally optimal but globally inferior solutions. My main gripes include frontend developers that don't understand HTTP and backend developers that don't understand SQL.
And besides, where does your notion of "full stack" begin? Is it backend application code? Operating system libraries? Kernel code? Hardware drivers? I'd argue "full stack developer" is a misnomer anyway, since no developer can (or would want to) write both kernel drivers and html/css frontends.
> since no developer can (or would want to) write both kernel drivers and html/css frontends.
You do realize this comment is going to pull the exceptions out of the woodwork?
I wrote all of the software for the first version of the Teledyne Lumenera Ethernet cameras. Everything from assembly codes in the bootloader to CSS in the on-camera web pages. Heck, I even had to review and debug the PCB design before I could start.
I don't think this is a particularly uncommon experience. Embedded development usually has very small teams, and very often the hardware has HTTP API's.
P.S. I'm available for work. Information in profile.
Yeah, it's probably my personal bias showing. I'm fine with most parts of the stack (like you, down to PCB design), but UI/GUI/WUI work is an area that I try very hard to avoid.
I dunno...that's actually my job. :) I work (mostly) doing embedded software (drivers/os/apps) but also help with some of the supporting back end web services and yeah, some of the front end code as well.
It's handy for the company since I can work on whatever's most needful from week-to-week as well as take features from device to backend to production.
Why would I want to? Well, I get to learn (more) new things and the scenery changes more often.
It's not a bad gig if you can pull it off.
The problem in both cases is being an asshole who doesn't respect the value of other people's skills.
The main thing "wrong" with a specialist is that not every org needs a full time specialist, so specialists are more likely to need to work as consultants.
I agree with the notion that "full stack" means different things for everyone but there's a difference between a specialist and someone who only knows html/css. I've normalized relational dbs, made REST and GraphQL APIs but I specialize in making the frontend applications (web/ios/android/etc). I can wear all the hats on my side projects but they're not gonna pay me double for working the whole stack
this so much. Can't count the number of times I've been ignored after warning others about things that will happen down the line cause I don't just throw the pig over the wall to the testers and ops guys and consider the job done. I'm usually able to see problems that will pop up later down the line since I've done the code writing, and the testing, and setup the CI/CD process, all the security hardening and STIGs, and after they ignore me I tend to be the one helping them fix it.
When I interview for jobs they always ask very specialized questions. Everyone wants a generalist but refuse to interview them or pay them like one.
The idea that you can't be great at very different things isn't confined to software engineering. I think it's because most people can only master one thing so they can't imagine other people working differently
To be perfectly fair though even “mastering” backend is quite close to impossible.
You’ve probably heard of the 10,000 hour rule, it’s a hard and fast rule to say that it takes roughly 10,000 hours of doing something to fully master it.
Maybe not true in all cases; but consider the suite of tools you have to be practicing every day to do even a single role: VCS/DVCS, shell, OS fundamentals, build-systems, networking, DNS… now we have distributed computing concepts such as kubernetes and various DSLs, then there’s your programming language(s), their standard libraries, their extended contrib libraries.
Completely non-exhaustive list and we’re already closing in on 5 years working full time for each of those.
The sheer hubris of assuming you can throw together a few frameworks and understand 1 or 2 paradigms and then claim you know “the whole stack” is immature and exhausting; similar to the sysadmins of yore who could read QuickStarts and claim to know how to maintain software fully.
Delivering business value is definitely what we’re trying to do, but when it comes down to it: engineering is understanding; and nobody can claim to understand everything, not with a straight face.
Full Stack is either: the most senior you can be or
the most surface level you can be.
If the former: we can’t afford you and I’m not sure how you managed to keep all your skills up to date.
If the latter then specialists will need to clean up after you anyway.
Fist, the 10,000 hour rule is false common knowledge [1,2].
Second, splitting a general role ("backend engineering") in arbitrary atomic skills doesn't make sense because there's no end to it. Backend engineering -> OS fundamentals -> Driver programming -> Hardware design -> Boolean logic -> Set theory -> and so on...
Third, all engineering roles have cross-cutting concerns. You do need some network knowledge to be a "backend guy"... but also to be a sysadmin, devops, etc.. It's not like all these roles exist in a vacuum and you're starting from 0 if you switch between them.
Finally, most people that think of themselves as experts in some role, language or framework end up in the "1 year of experience repeated 10 times" trap. True experts are also somewhat generalists too, because you can't built a tall knowledge without growing the base too (pun intended).
10,000 hours, whether true or not, is a ballpark and even if it's patently untrue: it will always require some non-trivial amount of time to get good or master a particular subject.
Not all subjects are equal, granted.
having overlap in knowledge between roles is also somewhat granted; being a complete master in backend gives a person a lot of knowledge towards being a sysadmin (maybe even 60-70% of the way to being a master in that direction!);
But, you've failed to convince me that any single human on earth can do "everything"; even if a person could literally master all technologies in use (not counting your strawman of driver programming) then there would still be a discipline mismatch.
I'm not sure I understood the point you tried to make
Nevertheless, I have a solid understanding on all the things you mentioned and if you need help give me a holler because my rates are fair and I'm open to opportunities
I think the differentiating factor, for me, if I were in a hiring position, would be that full-stack engineers are curious, flexible, and both eager and very able to learn.
Specialists, I have less experience with working with them though so take these generalizations with a big and hopefully non-insulting grain of salt. On the one hand they will be experts in their field, know whatever they work on inside-out, and can squeeze every last grain of performance out of it - good DBA's are worth their weight in gold, they can solve a company's performance problems and save them millions depending on the scale.
On the other you have a group of people that sorta know one language, like Java, and will just coast along on it for their careers; their CVs will look impressive, their skills will be indistinguishable from someone who has one year of experience. I've literally seen code that was a copy / paste of the first google search result of "java sql query", buried ten indentation levels deep, in a critical core codebase.
