41–50 of 59 posts
"Never memorize what you can look up in books." When you do it long enough, you get a really good sense of the structure of programs. Then, it's just a matter of fitting in the best technologies of the time into the 'architecture'. The full stack is just data storage, data transfer, processing, user interface, system structure, tools, and processes. When you do it long enough, you get a good, general understanding of…
If you don't want to learn new things don't take jobs that require something you don't know. Take jobs that require the skills you already have.
Note that this strategy wears down. If you started this strategy 8 years ago, you'd be making websites with cgi, perl, and asp and desktop apps with Visual Basic and Access. If you're going to be a developer for more than a handful of years, you're going to need to be prepared to retrain yourself on new things every few years.
You jump around jobs and see where it gets you. Eventually, you realize how to pick and choose your tech. I got real burn out with front end, with emberjs, angularjs, and now react. I'm going to just wait this out until ES6 come about and see where that go. I think in general I moved toward back end with all the big data and data science is going to be at. And now I'm going back to school to become a data science pra…
> I've seen people talking about how full stack is unicorn. I'm a full stack but I'm experienced in many technologies Can you debug your runtime (Ruby, Python, the JVM, whatever) in gdb? I can, and I still don't consider myself "full-stack"--both because I leave JavaScript to JavaScript people, but also because if you asked me to debug a kernel I'd look at you and just shrug. The stack goes down past your application…
So for me that's HTML, CSS (Less/Sass), JS (React, Angular, jQ), on the frontend and then a choice between Node, PHP, Ruby, or Python plus DBMS on the backend depending on the requirements / my mood.
The only bits that really extend beyond that are interfacing with external libraries such as ffmpeg, imagemagick etc.
I've not seen any instances of full-stack implying heavy dev-ps experience for example. And that's in 12 years of pissing my life away being a "full-stack" developer.
Heck, right now I'm employed as a "front-end web developer" and spent last week writing an API-only Node app and configuring TC/Azure deployments and NginX.
Anyway, got a bit off track here... my original point was that "full stack" is pretty well defined and has been for a long time.
Earlier quoted context omitted.
> I've seen people talking about how full stack is unicorn. I'm a full stack but I'm experienced in many technologies Can you debug your runtime (Ruby, Python, the JVM, whatever) in gdb? I can, and I still don't consider myself "full-stack"--both because I leave JavaScript to JavaScript people, but also because if you asked me to debug a kernel I'd look at you and just shrug. The stack goes down past your application…
Full stack to me means "Given a design and a brief, can turn it into a reality with no external help". So for me that's HTML, CSS (Less/Sass), JS (React, Angular, jQ), on the frontend and then a choice between Node, PHP, Ruby, or Python plus DBMS on the backend depending on the requirements / my mood. The only bits that really extend beyond that are interfacing with external libraries such as ffmpeg, imagemagick etc.…
"Never memorize what you can look up in books." When you do it long enough, you get a really good sense of the structure of programs. Then, it's just a matter of fitting in the best technologies of the time into the 'architecture'. The full stack is just data storage, data transfer, processing, user interface, system structure, tools, and processes. When you do it long enough, you get a good, general understanding of…
I suppose you can still focus on a few technologies when looking for new projects and freelancing. At the beginning it should be quite complicated since you won't like the idea of letting a project go just because it requires some new framework you don't know, but it's a price to be paid in order to have more expertise and experience using your skillset (proper financial planning might help in this transition). If yo…
But most developers i know are proficient in multiple frameworks and languages, that's why i'm trying to be at least good in them, i suppose the only way to do so is to create a repo for each new thing i learn in github and make sure to put a new project in each rep every week
I have a lot of tricks in my toolbox to seem ready and productive, while I'm scrambling behind the scenes to actually become ready and productive. (Difference is, I'm willing to admit it, because I am confident in the value I create.)
I don't. I understand the principles of the stuff I use and can draw upon past experience to analogize to new stuff. Like, despite what a lot of the Node community will tell you, a Reactor model on N threads (where their N = 1) is not new. I saw it in Java, with Netty, most of a decade ago and you see it today, albeit abstracted from you a little, in Play. At a gig last year, I was able to build out a plan of attack…
I find it's pretty important to know the kind of thing (what it does, the 1000ft view, the basics of the area that it's attacking) and then the differences between the (generally guaranteed to exist) alternatives/other products that do the exact same thing.
Long Example:
Databases - You should know what a database is. How have people done databases in the last 50 years? 40? 30? 20? 10? now? (while that seems like a lot of research, it's generally not - as much as some things change, a lot have not changed for a long time in CS). What are the big theories that propel most of the solutions? ( for databases you might find stuff like mmap, b-trees, indexing, hashing)
Then, there is the question of what is the difference between Postgres & MySQL? MSSQL & Oracle? RBDMS & NoSQL? RethinkDB/Mongo & Neo4J?
I generally find that knowing stuff in those frames is more than enough. Personally, this approach works but I am embarrassed when I have to look up things like "how to list all the tables in mysql" on Google, but I'm starting to think that's not such a big deal. Yes, I don't know every oracle/microsoft/mysql/postgres command, but I think it would be more ridiculous to take the time to try hard to memorize stuff like that, and then completely miss out on the benefits of NoSQL databases, for example.
Also -- do tons of side projects.
Earlier quoted context omitted.
Full stack to me means "Given a design and a brief, can turn it into a reality with no external help". So for me that's HTML, CSS (Less/Sass), JS (React, Angular, jQ), on the frontend and then a choice between Node, PHP, Ruby, or Python plus DBMS on the backend depending on the requirements / my mood. The only bits that really extend beyond that are interfacing with external libraries such as ffmpeg, imagemagick etc.…
If you think running gdb when something breaks is "devops", we may simply not have compatible vocabularies. I consider it a fairly foundational part of making a product that works.
The line generally gets drawn at "Does it run on one server?", in my experience.
I suspect if Docker pans out like it wants to that will change though, but perhaps that's my naiivety showing through