[HN Gopher] Ask HN: Moving from tiny websites to serious tech sk...
___________________________________________________________________
Ask HN: Moving from tiny websites to serious tech skills?
I'm a self-taught web coder and have made some small CRUD systems
for very targeted tiny clients during my professional life. I have
also made a few hobby sites for fun just for myself. I'd like to
expand my skill set but I have trouble visualizing all the moving
parts of a "big" web app and all the tools that go into it--when
people talk about containers, or testing, or deploying such-and-
such, I don't have a clue. With HTML/CSS/JS, I can spin up a little
demo to play around and learn on another personal/toy project, but
how do I, as a solo person, learn about larger-scale technologies?
I'm a visual artist and print-based technician so front-end would
probably be the place to focus. Is there a recommended path for
going from hobby projects & small sites to larger-scale best
practices in React/another important platform?
Author : neonnoodle
Score : 101 points
Date : 2021-12-26 13:17 UTC (9 hours ago)
| kettleballroll wrote:
| Yo! I'm mostly doing back-end development as a hobby and to learn
| some new tech (ai researcher by trade), and I'm looking to join
| forces with a front end person to work on larger projects. Shoot
| me a message if you're up to it, we can explore this space
| together. (Mind you, I'm doing this as a hobby, so time
| commitment varies a lot.)
| imajoredinecon wrote:
| Find an interesting open source project with active and friendly
| maintainers (this might take a bit of looking). Figure out how to
| check out and build the code, then choose an open bug and fix it
| (or find a small open feature request and implement it). This
| will require learning how to read code in a bigger codebase and
| make targeted changes, which is basically the first thing you
| need to be able to do as a software professional.
| NicoJuicy wrote:
| I'm a solo coder in my private time and work at a big Enterprise
| full-time.
|
| Keep it simple for your own. Use git, but you don't need CI. ( VS
| has an awesome publish option for example)
|
| Know the tools you know and use them required. Sometimes there
| are frameworks that help you speedup coding *5 ( eg. A screenshot
| from a web page is much easier through node), but i know c# the
| best. So 85% of my projects are in. Net.
|
| If you don't know a backend framework. Consider RoR because of
| it's scaffolding. Do you work on Windows, give Visual Studio
| community a try. Pick a framework that is batteries included (
| registration, login ) without jwt in the beginning.
|
| For my projects after work, using asp.net MVC with EF and using
| scaffolding is a 500% quicker turnaround ( easy) than using any
| SPA framework.
|
| Don't do cloud, it's expensive and for enterprise. Self-Host with
| a cheap VPS. Maintenance isn't as much as many claim. Implement
| some security measures! ( Private key ssh, firewall ( is always
| free)... )
|
| What's your goal? Create your projects as cheap as possible and
| as fast as possible, if it doesn't gain traction. Then you could
| take above into consideration and use boring technology (
| http://boringtechnology.club/ )
|
| Is it purely to learn? Do some certifications about the cloud and
| spend halve a year learning non transferable skills with vendor
| lock in ( AWS, Azure, GKE, ...)
| burlesona wrote:
| I started almost exactly where you were about 12 years ago. Came
| from a graphic design background, knew HTML and CSS really well,
| was decent at client side JS. I knew some PHP from hacking on
| Wordpress sites, but struggled to grok the rest of the web.
|
| The best thing I did was grab a Rails book and study it, building
| the sample project all the way through. Then I came up with a web
| app I wanted for myself and built that using what I had learned.
| This took some time, but taught me so much. First, it forced me
| to learn another ecosystem, which made me much more aware of what
| was "common" or "universal" among web applications versus what
| was environment-specific. It also made me learn a new language,
| which similarly gave me a much better understanding of how
| computer programs work (seeing the same basic things implemented
| differently helped me understand the fundamental concepts that
| every language is abstracting over).
|
| I would definitely still recommend this approach today,
| specifically because Rails is such a well-documented full-stack
| framework, it's really easy to learn. Start here:
| https://www.railstutorial.org/
|
| Another advantage is Rails is the tech underlying many of the web
| giants (GitHub, Shopify, AirBNB, etc), and the Ruby ecosystem
| inspired many of the other cool new technologies out there today.
| Even though it's not the "hot new thing" anymore it's extremely
| marketable. React devs are a dime a dozen, but people with Rails
| experience are in high demand and much harder to find.
|
| The last thing is you just need to get a job at a place with
| other good engineers who can mentor you. Ultimately everything
| else is just getting your skills up enough to get in the door,
| once you clear that hurdle you'll be able to learn as you go.
|
| Best of luck on your journey, it's hard work but very, very
| rewarding! Happy to answer questions if you have any :)
| vasco wrote:
| Since other comments already point to getting a job, I'd mention
| other options. One is going to university and being exposed to
| more technologies and most importantly, meeting other people and
| working with them. Other similar options are going through the
| syllabus yourself and partnering with other people in hackathons
| or similar group events.
|
| I would like to also offer a different perspective on the idea of
| "big" web apps or more "professional" setups. If what you want is
| to be able to do more complex projects for your customers or for
| yourself, just do that. Solve the problems you need to accomplish
| your goals. Maybe your development cadence could improve from
| getting better at testing. Maybe you're not happy not knowing how
| to maintain or deploy your code. Focus on your path and your
| problems and forget about what you "should" be doing. That's how
| most people become proficient engineers. Meanwhile keep up with
| industry news and read a few books per year, and know that the
| best way to really kick this into overdrive is working alongside
| more experienced people in a team.
| hackandtrip wrote:
| After ~2y of professional experience, I don't think that there is
| huge hard skill gap between non-professional and professional
| devs.
|
| The biggest thing is understanding that you may work on a single
| tool in ~10/100 people, so you must develop and work with other
| people in mind. So, modularity, enforcing code clarity and
| writing good tests, understanding product decisions and so on...
| Personally, I learnt this stuff on the job pretty fast - still
| newbie, but can autonomously solve medium/complex projects
| without senior help, which should be a base goal.
|
| Larger-scale technologies is mostly larger-scale organization -
| just apply to one of those and I am sure you'll catch up fast
| celim307 wrote:
| There's also "levels" to the scale of stuff you wanna learn. You
| can learn deployments, testing etc that will carry over from
| small teams up to huge big tech size teams, but I've worked on
| projects with 200+ active maintainers and the problems there are
| different than problems and architecture you would find in a team
| of 10
| mellosouls wrote:
| As others have said, the best path is to join an organisation
| building those things, but if you insist on
|
| _as a solo person_
|
| There are plenty of good resources online, free and paid. Paid
| options like Pluralsight have the most easy to find quality
| curated content that can guide you; alternatives like Cloud
| Academy will give you hands on labs.
|
| That's obviously in addition to the endless stuff on YouTube (the
| difficulty here is separating the wheat from the chaff) and in
| books and articles.
|
| Only by diving into dedicated, expert resources like those will
| you get the context, but mentoring within a team will be the
| fastest and surest way to competence on larger systems. Look for
| a job in a team.
| krisoft wrote:
| I don't want to discourage you, but why do you want to learn
| these "large-scale" technologies?
|
| Tools are tools. They solve some problem. Many of the large-scale
| companies have problems you as a single frontend developer might
| not. If we better understand what is your motivation maybe we can
| better advise you which techniques are worth your time.
|
| Are you interested because you would want to join a big company?
| Then it is a question of how to get a portfolio which you can use
| to get through the filters.
|
| Are you interested because you have trouble keeping up with some
| aspects of your solo developed projects?
|
| Are you perhaps feeling that your simple solutions are bad just
| because they are simple? In that case it is important to know
| that what is best practice for a team with 200 developers might
| be a terrible waste of time for an individual.
| siva7 wrote:
| Sometimes discouraging people is the best way to encourage them
| finding a better path. Over my career the golden rule i've
| learned is: Learn the technology stack when you need it to
| solve a specific problem. Everything else is likely premature
| optimisation. If you want to grow as a developer you have to
| join a team. There is no shortcut to this.
| jacquesm wrote:
| This is very good advice and applies to many more things than
| just technology.
| nowherebeen wrote:
| This. Websites are just marketing tools to sell your product.
| Unless your product is the actual web-app, I would steer away
| from learning complex technologies. They tend to come with
| their own operational overhead. When in doubt, follow the KISS
| principle.
| evolve2k wrote:
| Hey I am also a coder and designer. My strong suggestion;
| actively seek the 'seam' where art/design and code meet.
|
| You'll have more success (and fun) doing things where you can
| leverage your creative skill alongside your code learnings.
|
| One source of deep admiration for many Ruby programmers was the
| artist/coder "Why the Lucky Stiff". They created digital works of
| art that were a serious of small coding projects most of them
| fun, a couple highly useful.
|
| The seminal book "Why's Poignant Guide to Ruby"
| (http://poignant.guide) is still a beautiful read. Pair it with
| the website Try Ruby (https://try.ruby-lang.org) and you can plug
| in the examples from the poignant guide as you read along.
|
| I'd recommend learning Hotwire and Rails 7 and then making small
| Rails apps to create small artistically interesting sites.
|
| Ruby and Rails is highly attractive to people who value asthetics
| and beauty, and helps you integrate your creative impulses with
| how you code. Most languages don't account for or attempt to
| address beauty in how you code. It's by no means necessary but
| has been delightful for me finding a language and community that
| often highly values deep inner creativity along side coding
| principals.
| hnarayanan wrote:
| I'd be happy to mentor you if you're interested. My profile here
| has information to get in touch.
| johncoltrane wrote:
| You won't get there if you stay solo, so get hired, join a team
| and learn as much as you can from your peers. Large-scale is
| team-scale.
| csbartus wrote:
| You'll get there also alone, if that's your type. Artists are
| independent, self learners.
|
| What I suggest for front-end is a component based approach:
| React, Vue, Svelte, Lit. Components are a new paradigm, there
| are here to stay. I also suggest to learn "The new responsive"
| from web.dev - in the same way the future.
| bad_interivewee wrote:
| how does one simply "get hired" while being mid career with no
| professional sw experience? asking for a friend.
| paxys wrote:
| If you classify yourself as mid career then by definition you
| need to have professional experience (and consulting,
| freelance development, volunteering etc. all count).
| Otherwise look for entry level roles.
| bad_interivewee wrote:
| Mid 30s, a couple corporate experiences (non sw) and the
| rest "freelance". Usually raises suspicion (lack of
| continuity) or gets discounted as not meaningful/relevant.
| Do entry levels consider anyone other than new-grads?
| Haven't gotten a reply from any in the past.
| mkoryak wrote:
| Look for a company where software is not their main focus.
| Get hired there by showing them some projects on GitHub.
| Don't have projects on GitHub? You can make those be there
| right now for free.
|
| You will also need to interview there. Your username
| indicates that you suck at interviewing. I hate to break it
| to you, but interviewing is a skill that can be learned.
| With. Practice. You can either interview at places or try a
| site like interviewing.io You can get better at interviewing,
| trust me.
|
| Once you get hired to the not-so-software company, use that
| experience as a stepping stone to get hired somewhere better.
| Repeat until you find a place you like
| bad_interivewee wrote:
| i don't have any public facing repos, so i'll clean some up
| and try to emphasize that a bit more.
|
| in terms of interviewing, no opportunities so no
| experience. in the past ive had to apply to roughly 80 jobs
| to get one interview. recruiters on linkedin are a little
| better at ~30 conversations per interview but its plain
| exhausting, takes a ton of time, they demand replies
| instantly or ghost, but really its overwhelmingly likely
| they'll ghost me anyways.
|
| its been a while since the last round of attempts so ill
| give your suggestions a shot in a few weeks. thanks
| mkoryak wrote:
| Having something that stands out on the resume will go a
| long way for you. A nice looking GitHub profile with some
| pinned repos with activity and a nice readme is what I
| would recommend.
|
| You can also find an existing project and contribute to
| it. What's your GitHub username? I can follow you
| ultrasounder wrote:
| gxespino wrote:
| Spend less time applying and more time truly polishing up
| one or two repos/side projects. Cleaning up a few repos
| is the bare minimum here.
| malwrar wrote:
| I'll add, remote work means you could literally practice
| this in your bed. I've been on both ends of an interview
| now sitting in bed in my PJs and let me tell you I have
| never felt more royal in my life!
| vmception wrote:
| incorporate your software company
|
| list a couple clients if you can
|
| point out that you've been working for that (your) software
| company for several years as a senior software engineer
|
| pass bullshit brainteaser problems
|
| viola
| bad_interivewee wrote:
| ive had a corp for a while but never called myself "senior
| engineer". maybe ill give that a shot.
| camb416 wrote:
| As a Tech Director, I don't like this. We're not fooled
| by this kind of thing. I'd rather see someone dedicated
| to learning and growing, but that's just me maybe.
| bad_interivewee wrote:
| not trying to "fool" anyone, trying to get an
| opportunity. ive had to apply to hundreds of places to
| get a handful of replies.
|
| been learning and growing for 3 decades starting on a IIe
| but highlighting that part hasn't worked so why not
| experiment with my approach?
| ultrasounder wrote:
| Ha! I copy-pasted your response from last weeks thread
| above. What a great response. Ima try it in the new year
| myself. Already incorporated llc. Building my static site
| this week and off to the leet races I go.
| seaknoll wrote:
| Practice algorithms and read about software design in your
| spare time. Apply to tons of companies, be prepared to be
| rejected from almost all of them, and to be asked questions
| that you have no intelligent answer to. Remember what they
| asked you, learn the problems you got wrong, and repeat. It
| may be brutal and embarrassing at times but if you keep at it
| you will eventually get a job. The only thing I can say about
| maintaining any sense of morale is to take some pride in the
| fact that you're pushing yourself, and that tons of people
| have had the same shitty interviewing experience but gotten
| through it and realized it was 1000% worth the pain.
| bad_interivewee wrote:
| the leetcode/algo question stuff is mentioned here on HN
| alot but I've never gotten to the point where a test was
| actually offered to me. will start practicing though and
| hopefully an opportunity pops up.
| seaknoll wrote:
| In that case, you might want to have a
| friend/acquaintance with a job like what you want to
| review your resume and give you feedback on that and a
| first round-style interview. If you don't know anyone who
| can, read over resumes on linkedin, and pay close
| attention to the language used, and to the extent that
| it's relevant to your work try to mirror it. Try to be
| direct and confident about what you know/don't know
| during the interview, and try to at least learn how to
| talk about technologies that touch what you're more
| expert in.
| smus wrote:
| If you're not getting calls, it's your resume that is
| bad. That either means the format, or the content. Seems
| to me the only change to the content that you can make is
| working on and advertising well written open source
| personal projects that your interviewers can see, or
| contributing to large open source projects.
| johncoltrane wrote:
| Web agencies would be a good start.
|
| Expanding on the above... I work at such a place and our bar
| for recruitment is a lot lower than that of more snooty
| companies principally focused on software. If you can
| demonstrate potential then it will be relatively easy to get
| in. From there, you will start working on projects larger
| than what you are used to, that _won't be_ "the next
| $FAMOUS_THING" while still offering plenty of learning
| opportunities.
| bad_interivewee wrote:
| a few years ago i did manage to get a pm/ba type role at a
| small-medium size agency. giant mess of a place (norm for
| that industry i guess) but it was a meat grinder - all
| about billable hours (which were hard to come by since
| every project was undersold and over budget), which meant I
| worked 50+ hours every week with no salary increase or
| bonus. burnt out and left when it was obvious there was no
| opportunity there. although to your point the place was a
| revolving door and SO many hires were gone after 3-6
| months, so perhaps ill look for places like that.
| atian wrote:
| Second this. Most of the action is proprietary.
| sandstrom wrote:
| Yeah, this is the answer.
|
| To add to this, for the "large scale technologies" you're
| interested in, remember that there aren't many individuals that
| knows it all (and neither will you!).
|
| Senior engineers and CTOs will have a rudimentary knowledge of
| a lot of the moving pieces, but it's primarily a team effort.
| Even if you "knew it all", you wouldn't have enough hours in
| the day to keep it all up to date and running. Running any
| larger piece of software is a team effort.
|
| But as a member of a team you'll still get a much better idea
| of all the pieces, even though you won't be able to master them
| all.
| MichaelRazum wrote:
| Have to agree. Especially in the beginning, it is important to
| have some experienced devs around. Later you could try to go on
| your own, but very difficult in the beginning.
| flats wrote:
| Yes, agreed. I was in almost the same boat, mostly building
| small websites as a freelancer and wanting to learn more and
| work on more interesting problems.
|
| I went a 3-month programming bootcamp, got hired as a junior
| software engineer at a non-profit with a small engineering team
| (~10 people), and learned a _ton_ about the sorts of things
| you're talking about (automated testing and deployment,
| container technology, JS pipelines, etc.). I also became a much
| better programmer through years of code reviews and pair
| programming. If you can find a place that's big enough to have
| several people far more experienced than yourself and at least
| one of them is willing to help you out when you need it, you'll
| probably get where you're trying to go!
| yucky wrote:
| This is what I would advise as well.
|
| Look at marketing agencies especially, where they typically do
| more than dev, but need some dev skills in house. Focus on
| Wordpress for smaller projects and use Laravel as a framework
| for larger stuff. You'd be surprised how many businesses just
| want a Wordpress site as part of a larger marketing initiative,
| so be proficient there and you can make money. And the Laravel
| ecosystem has everything you need for large scale web projects,
| with Laracasts being a great resource to learn.
| Pandabob wrote:
| I'll give this a shot:
|
| 1. Learn React and Typescript. React has taken root in the
| enterprise and it seems to be the frontend equivalent of Java.
|
| 2. Learn about CI/CD: Github Actions is a good starting place. If
| you're hosting your projects in something like Vercel, try
| running separate staging and production environments.
|
| 3. Look at popular open source frontend projects. The newly
| released Supabase dashboard[0] seems to be a pretty good starting
| point to figure out modern best practices. Excalidraw is
| another[1].
|
| 4. Frontend masters has some pretty good courses regarding React
| and enterprise Typescript. Would give those a try (the price is
| $39/month).
|
| 5. Where I'm from (Finland) Spring Boot (Java/Kotlin) seems to be
| the most popular backend framework. Node and Python frameworks
| share the second place. If you want to learn backend, I'd suggest
| picking one of those three. Rails if you really want to.
|
| 6. At some point you'll probably want to work with AWS. If React
| is the Java of the frontend then AWS is the Java of
| infrastructure.
|
| 7. It's never a bad idea to know SQL.
|
| [0]: https://github.com/supabase/supabase/tree/master/studio
|
| [1]: https://github.com/excalidraw/excalidraw
| brightball wrote:
| I'd bump 7 to the front of the list but otherwise, totally
| agree.
| Pandabob wrote:
| I don't disagree with this. SQL keeps the world turning.
| vanusa wrote:
| Yup - it's probably the most resilient innovation in software
| out there, right after assembly language.
| lytefm wrote:
| This sounds like good advice. Don't worry about Containers,
| deployment or testing "best practices" until you really need
| it.
|
| You'd be surprised at how many software companies' testing is
| "clicking around in the app", deployment is "upload to store/
| rsync to server" and containers aren't used at all.
|
| Start learning React (you can also take a look at Vue), do some
| tutorials and build some CRUD app which has a database.
|
| Stay focused on the front-end, learn "just enough" of
| everything else when it comes up. I'd recommend getting into
| Cross-Platform Web app development using something like
| Electron (Desktop) or React Native/ Ionic (iOS/Android).
|
| After learning the basics, dive into some frontend-heavy open
| source project that uses your framework, figure out how it
| works and try to fix some bugs.
|
| For example, this is a Markdown editor using Vue and Electron:
|
| https://github.com/marktext/marktext
| vanusa wrote:
| _You 'd be surprised at how many software companies' testing
| is "clicking around in the app", deployment is "upload to
| store/ rsync to server" and containers aren't used at all._
|
| Not only that - a non-dockerized, bare-metal, but otherwise
| cleanly coded "rsync to server" app can be -- compared to the
| usual non-spec'd, undocumented cluster-f hairball shoved into
| a container, with a shiny layer of CICD thrown on top -- can
| be surprisingly joyful to maintain.
| jraph wrote:
| And it's usually not the frontend/backend developer
| deploying the app, but a dedicated person in charge of
| deploying / maintaining the infrastructure.
|
| But it helps to have an idea on how they work.
| didip wrote:
| Software is like water. It fills up whatever medium provided.
|
| The easiest way find and learn big tech is to work for a big-ish
| tech company with a big problem to solve.
| BackBlast wrote:
| Front end scales marvelously. Distribution is easy and cheap.
| Learn whatever front end framework you like best and learn to
| make a fat client that does most to all of the heavy lifting in
| the client.
|
| Scales wonderfully.
|
| Scaling backend data structures is a difficulty itself and
| potentially different for every problem.
| ohmyohmy wrote:
| fayazara wrote:
| I think the best way to achieve this is to either join a tech
| heavy product based team or keep building side projects and I
| mean like proper projects and make a saas out of it. This coul
| cover a lot of use cases for you.
| davesailer wrote:
| I started reading the following a couple of nights back. Might
| give you some help if you haven't already seen it:
|
| The Passionate Programmer (2nd edition) Creating a Remarkable
| Career in Software Development by Chad Fowler
| https://pragprog.com/titles/cfcar2/the-passionate-programmer...
|
| You can check it out before buying at either of the following:
|
| https://www.pdfdrive.com/search?q=chad+fowler&pagecount=&pub...
| OR https://u1lib.org/s/chad%20fowler
| xwolfi wrote:
| Hum honesyly container: use them for like bittorrent
| (rtorrent/sonarr) and you ll get how they work, testing:
| absolutely add tests to whatever you were doing before, and
| deployment is trivial if you understand running from cli.
|
| Tbh at work I see people who can deploy a container on the cloud
| but have no clue how to start the program quickly to check
| something lol, so ...
| assuringllama wrote:
| I am a self-taught software engineer back in 2016. After
| launching my first SaaS, I realise for me to grow, I need to
| learn from people way better than me. I manage to find my first
| software engineering job in 2017 and never look back.
|
| I believe the best way to learn is from people better than you.
| The problem with small projects is that it never make it to the
| point where certain skills/practices become important or even
| critical.
|
| In this spirit, my recommendation is in this order: 1. Get a job.
| Learn how to work in a team. 2. If for some reasons, this is not
| possible, watch conference talks especially on those problems
| faced by big companies, and what do they do to solve it. Learn
| about this problem, and figure out other ways.
| felipemesquita wrote:
| I think Ruby on Rails might be a great framework for
| incrementally learning the complex parts of a serious web app. I
| would recommend you check out DHH's recent tour of the
| framework's seventh version, and if you like it, check ou the
| Rails for Beginners video series by GoRails on YouTube, or Michel
| Hartl's Ruby on Rails Tutorial book.
| getup8 wrote:
| I'm a fan of just learning as you go. It sounds like you've built
| relatively simple apps so maybe try to build something more
| complex, even if a "stupid" idea.
|
| Try React or Vue with some database component and go from there.
|
| And before you start, look up a resource for how to write good
| tests with the tech you choose, and work on that as you go as
| well.
|
| Good luck!
| ufmace wrote:
| In addition to the many other suggestions here, there's plenty of
| ways to practice improving your current apps. Some examples I can
| think of from your description:
|
| How are you doing deployments right now? Do you have a bunch of
| manual steps that have to happen in the right order, can you do a
| rollback quickly if you have to? Try learning some better
| deployment technologies that fix those problems. You might not
| have been bitten hard by any of them yet, but you never know when
| it could happen.
|
| How about logging and monitoring, have you integrated with any
| tools that could allow you to monitor performance and error rates
| from all of your sites? That's also worth doing if you haven't
| already.
|
| Are you using source control best-practices and CI/CD systems?
| Are your repos set up such that a new contributor could get
| onboarded to them easily? If not, do that. Try spinning up a VM
| or something and getting your repos set up on them, and fix or
| clarify as many manual steps as possible.
| have_faith wrote:
| Being autodidactic myself the best method I've found is to simply
| over-engineer your personal projects for the sake of learning. I
| have side projects that I've never even launched that are built
| using whatever I could find as "best practice" for solving that
| particular problem at scale.
| Veen wrote:
| This how I learned various technologies. I often re-implement
| my personal invoicing system (I'm a freelance copywriter) in
| whatever technology I am interested in: i) PWA with a react
| front-end, ii) AWK-based invoice processing iii) massively
| overcomplicated system based on Elixir and Phoenix Liveview,
| etc. I've also done something similar with a personal flood
| monitoring app (I live near a river prone to flooding). I'll
| never be a real developer, but it helps me to understand the
| technologies a little and know when they might be useful for
| something I want to make.
| tyingq wrote:
| If the original poster's goal is just to learn about things,
| this seems like a good answer. I would recommend trying one new
| thing at a time, though, rather than trying to do it all in one
| experiment. So if you want to move from your current vanilla
| html/js/css to a multi-tier-with-database, some framework
| (react/vue/whatever) and containers...pick one to start with.
|
| You could, for example, deploy your existing simple stuff using
| k3s, a single-host, local, simplified kubernetes. Or spend
| $10-$30/month on a cheap hosted k8s instance, like digital
| ocean.
|
| Or, leave your deployment as-is, and just tackle moving from
| vanilla html/css/js to vue or react.
| throwaway984393 wrote:
| Take a gander at MediaWiki
| https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hac...
| https://www.mediawiki.org/wiki/New_Developers It's the code of
| Wikipedia, which is a big honkin' scale, mostly-modern web
| application. Read through those pages, join their IRC channel,
| ask them how you might get involved from the perspective of your
| current experience. The fantastic thing about open source
| websites is you don't have to "get hired", you just pitch in! :)
| And if you do contribute, it's great experience for your resume.
|
| You can also look around for overviews of web architectures.
| You're gonna wanna lean about software design/architecture in
| general, and branch out to learn about all the components of a
| modern web application. You can find all the components used in
| MediaWiki I'm sure!
|
| Personally I've been wanting to learn how to build Progressive
| Web Applications so I can make some apps for my phone without
| having to learn Java.
| eyelidlessness wrote:
| Definitely learn specific technologies and methodologies. But
| also look for mentorship. It doesn't have to be formal at all,
| find people whose work and/or talent you admire and learn from
| them. Don't be afraid to help them learn too, you probably have a
| lot to share too.
|
| This, more than any particular tech or approach, helped me more
| than anything. Just working with and learning from/with really
| talented people.
| haolez wrote:
| I would invest in learning Rails 7 and Hotwire. Seems to have a
| great ROI for the effort put in. It can scale pretty far as well
| and you will be able to focus more time on delivering value.
|
| The technical excellence road has a lot of dead ends and false
| prophets. Be aware!
| blablabla123 wrote:
| > I would invest in learning Rails 7 and Hotwire
|
| I'd definitely agree with Rails. IMHO it has been defining Web
| development for a long time. Even today patterns from Rails
| like are copied outside of the Rails context. Service Objects
| seem to be a recent example.
|
| Hotwire seems definitely cool tech but after having been
| exposed to Ruby on Rails it's possible to go into various
| directions. (Classical server-side rendering, Hotwire or e.g.
| React-based SPAs)
| ChrisMarshallNY wrote:
| Hate to be "that guy," but learning PHP is a not-so-bad way of
| getting into the system architecture field.
|
| I know that "PHP" is a dirty word, hereabouts, but I submit
| Exhibit A, the "fishtank graph":
| https://w3techs.com/technologies/history_overview/programmin...
|
| There are some really big, well-written (and badly-written)
| systems out there, in PHP, and it's a great place to learn
| about some of the baseline technologies that any aggregate
| Internet system will use.
|
| But I have never liked the language, myself, despite having
| developed some fair proficiency in it. These days, I like doing
| really nice frontend work, in native Swift. PHP is what I use
| to create backends. It works fine.
| haolez wrote:
| Yeah, it's a great option as well. Laravel has the same
| mindset.
| menor wrote:
| I was like you 7 years ago (graphic designer and did some small
| websites), and best thing I did was taking my savings and doing a
| coding bootcamp (Dev Bootcamp in SF).
|
| It helped me understand what stuff I still needed to learn, and
| how to work in a team. Also helped my confidence, seeing that I
| was able to work with other people, some of them had already jobs
| as programmers, and solve problems with them.
|
| After that I decided to work for others, but I could as well had
| continued doing frontend master courses and stuff like that, I
| think the Bootcamp taught me the "glue" between technologies, and
| how to think like a programmer.
|
| There are a lot of online Bootcamps now, so no need to go to
| another country like I did, I'd look for some bootcamp where you
| work together with other students, and that has great mentors
| with industry experience.
| peanut_worm wrote:
| For me it was getting a job and seeing how an actual company does
| things
| simonbarker87 wrote:
| Sorry to self promote but you might find some of the blog posts
| in my site helpful: https://CareerSwitchToCoding.com
|
| One of the main things I would say is that nothing can really
| prepare you for the jump because a large web app made by many
| developers over years is a very different kettle of fish to your
| own small projects.
|
| That said, making and deploying your own things start to finish
| gives you a great foundation to build from, your core skills will
| be fine, you will just need to learn how to orientate yourself in
| a big app and that's a skill you learn through doing.
| replwoacause wrote:
| Have you thought about learning some low code tools that could
| get you into a position of deploying a web app quicker, albeit
| placing some limitations on what you can achieve? The limitations
| you encounter may be acceptable to you considering your goals and
| this way you'll have something to show for your effort in much
| less time.
| [deleted]
| Mave83 wrote:
| Simple, you usually don't need that. Most devs now a days don't
| know how to build efficient websites. That's why they need a tech
| Stack like the Mount Everest and create a dependency hell. It was
| possible to serve more then 250k unique users per day from a
| single VM more than 10y ago on shitty hardware. You can deliver
| so much more on modern tech if you stick to KISS principle.
|
| But yes, some rare sites do need to scale above >1M unique users,
| that's where the trouble begins. You can start by benchmarking
| everything you build. Think of every line of code and optimize
| it, or you just build your stack in smaller pieces and scale out
| using modern tech Stack. The question is, what do you want to
| learn. The first way would learn you how to build efficient
| software, the second one would teach you how to waste lots of
| resources but be new, modern and a hipster. And in addition, now
| a days employees are so expensive, that a company don't care
| about Cloud costs if this makes dev faster.
| cunac wrote:
| not to be rude but 250K uniques users is 3 new users per second
| and doesn't say anything about concurrent users. Concurrent
| users are scaling problem
| vanusa wrote:
| There's a natural distribution to these things, so actually
| an average of 3 does in fact say "something" about the tail
| behavior of concurrents (that is, the highest values you can
| expect under peak load).
|
| As a rule of thumb: it's probably on the order of 5x-10x
| (absent outlier events); then look at your data to find out
| what it actually is (users are not evenly distributed across
| the day/week); then apply the usual 4x or so rule for
| capacity planning.
|
| That is to say - it isn't necessarily a scaling issue.
| Especially when you're just starting out and no one is
| looking at your damn app anyway. If it's well designed and
| cleanly built you'll have plenty of time to factor for scale
| when the time comes ( _if_ it comes).
| Nextgrid wrote:
| This really depends what you want to achieve.
|
| A lot of "serious" tech skills is either cargo-cults building
| engineering playgrounds to benefit their own career - they are
| truly only necessary in very narrow cases you're unlikely to see
| unless you operate at actual FAANG scale (VC-funded FAANG wannabe
| doesn't count).
|
| If your intent is to work at FAANG or a FAANG wannabe building
| engineering playgrounds then fair enough, these skills would be
| useful, however if you want to learn to solve your own problems
| keep in mind that most of the cargo culting is not necessary; I
| suggest you learn solutions as you encounter actual problems and
| it's fine for these solutions to be old-school and "uncool" such
| as Rails/Django or God forbid, PHP.
| jmagaro88 wrote:
| How about contributing to an open source code base for a backend
| or frontend web framework? Since a lot of these projects are
| built with scaling in mind and have often reached complexities
| far beyond the capabilities of a singular developer to write
| himself, learning how they work in depth can give you the
| opportunity to significantly "level up" your skills in an area
| adjacent to HTML/CSS/JS.
|
| If you don't know where to begin, you can start by reading the
| issues and pull requests for the project on GitHub, where there
| is often a discussion of how to solve problems from multiple
| different perspectives. When you've lurked around for a while and
| feel like you have something to say, consider commenting and
| starting communication with other people working on the project.
| When you hang around long enough and even start making pull
| requests of your own, you'll have newfound expertise and new
| contacts to ask questions who might already be experts in the
| technology you wish to become an expert in.
| baalimago wrote:
| A lot of the web stack is analogous to "real" stuff.
|
| Practice your database skills by implementing some project using
| indexedDB [1]. Practice your parallelization/efficiency skills by
| implementing some webworkers [2]. Practice your IAM skills by
| implementing some oauth2 API for some website [3]. And so forth.
|
| Look here [4] for most (if not all?) the web stack things which
| you could experiment with, many of which will reflect back at
| "the real thing". I've done this and it introduces concepts in a
| good way. It also forces a "natural" progression towards backend
| when you have to deal with stuff like https/self signed
| certificates, websockets and so forth.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/API/IndexedDB_A... [2]:
| https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
| [3]: https://developers.google.com/identity/protocols/oauth2 [4]:
| https://developer.mozilla.org/en-US/docs/Web/API
___________________________________________________________________
(page generated 2021-12-26 23:01 UTC)