For a long while now I’ve taken to perusing the /r/webdev subreddit, and have taken to doing my absolute best to answer any question I come across both in the beginner questions sticky thread and any up and coming posts in the new section. I’ve noticed over time many questions are asked quite often, so I thought I would go through and aggregate them into one place.
This comes up from time to time, often worded as “I want to learn X, but I don’t think there’s a demand for it” or “Why should I bother learning a new language”. It’s interesting to see people’s reasons for not pursuing it, but really, you shouldn’t need the community (of biased people one way or another) to tell you why you should learn the hip new language on the block. If you have any inkling of interest in it, go after it, don’t let it sit in the back of your mind as just another cool thing. There’s no reason you can’t spin up a project idea and build it in a completely new language, learning as you go so you can figure out how to apply it to real world use cases. We shouldn’t be so hesitant to pick up a new language. Another variation of this is “Should I learn Language X over Language Y” - you might be able to guess my conclusion, but my advice is try both. Seriously, what’s the worst that can happen. It might feel at first like you’re spreading yourself thin and becoming a master of none, but getting a taste of a language and it’s applications can absolutely lead to you earning for a much deeper knowledge of it. You just need to dip your toes in and get your feet wet. And please stop asking us, we’re biased as hell.
What a loaded question. Opinions vary, but you need to evaluate what your objective is. If you’re looking to build a portfolio, put the source code on GitHub - it’s still up in the air as to whether this is actually important, but I know for a fact my current employers did take a look and it helped showcase my skill as a developer. You’ll also learn the fundamentals of git and version control along the way, an absolutely essential skill every developer, frontend or backend, should know. Of course, potential employers likely want to see a working version as well, and this is where it gets a bit tricky. If you’re purely working on frontend with HTML, CSS and JavaScript GitHub pages will have you covered, but for anything requiring a backend I recommend buying a domain from the likes of Namecheap (I personally use for my domains but your mileage may vary) and a simple virtual server from DigitalOcean. While there are cheaper hosts out there, you can’t beat DO’s community and incredible interface. Regardless of who you pick, you’ll then want to read through some guides on deploying your app to a production server. You read that right, production server. By all means have a development server too if you want, but learning how to properly deploy to production and building a workflow around it (checking for bugs, testing, etc) is essential, especially when building up a portfolio. This varies from language to language so I can’t give any specifics on how to do this unfortunately.
These come in all shapes and sizes, from “I learned HTML and CSS, now what” to “I’m getting bored with PHP, what next”. This is really hard to answer when it’s the latter, but the former is pretty straightforward - learn JavaScript. The three fundamentals of frontend - HTML, CSS and JavaScript - are key in developing websites. And it’s cliche to say JavaScript knowledge can be transferred to the backend, so I won’t repeat it, but learning the language can be an entry point for different backend languages. Programming languages as a whole follow very similar design patterns, so while syntax will vary the fundamentals are pretty transferable. After you’ve learned the basic building blocks of the frontend, I usually recommend PHP - not because I work at a company that uses Drupal and PHP for everything, but because I truly believe it’s the fastest language to get up and running with on a server, with things like XAMPP for Windows and Apache or nginx + fpm for Linux or macOS. It’s also super easy to embed in normal HTML files, so you can mix it in with existing pages, making learning just a little bit easier. Once you’re comfortable programming in PHP, the world is your oyster. Take on a new language, master PHP and it’s quirks, it’s up to you. But those are (in my opinion) the basic building blocks for getting up and running as a web developer.
This is a bit of a rare post, but it does happen. The simple answer is read the damn fine print. And that doesn’t just mean in the contract you’re offered - look into their company, try to get a feel for the company culture, figure out if it’s a place you want to work. Peek beneath the covers and make sure to value yourself, because if the workplace is toxic they will take advantage of you not knowing your worth.
First of all, you screwed up when you didn’t get them to sign a legally binding contract. But hindsight is 20/20, and you need to learn from your mistakes. First, resist the urge to deface the website you just put up - it’s unprofessional and reflects badly on you too. Instead, just take it down and send a notice to the company or individual. Seriously, don’t do anything else - they can’t legally do anything to you, but vice versa. Next, start figuring out what your contract will look like. Since you’re an individual, you need to take this very seriously, figuring out what you value yourself at and working out an airtight payment method that works for both future clients and yourself. You might need to tailor this on a per-client basis, but once you have a template you’ll be good to go. Make sure to include space for them to insert their signature, then have them send it back to you, then keep it on file, forever. If they end up not paying you, you have documented proof they made an agreement and you can (if you really want) take legal action. And be sure to keep tweak the template with any feedback you might get back from clients.
Build stuff and then put it online. Write down an idea and do it - it helps if the project solves a problem you personally have, so you can be a good judge of whether it’s “done” or not. This matters more than you would imagine, because when building something you’re not truly excited for or passionate about, it starts to feel like a slog, something you have to do and less something you want to do. And make sure to work on them until they’re at least at an MVP (minimum viable product) state, where the core functionality is in place. Then you’re free to either continue expanding on it or put it aside and work on something else, which brings me to another piece of advice - never work on multiple projects at the same time. It’s tempting to, especially when you’re working on one and get inspiration for a feature or solve a blocker in another project, but you should keep shelved projects shelved and just add your ideas to a README file. This will help you complete projects instead of hip hopping between half finished ideas. Also look into adopting sprint development for your personal projects - this may or may not be practiced at your workplace, but it’s really handy when it comes to keeping track of what needs to be done before the next batch of tasks, instead of building everything and the kitchen sink all at once.
I’ll continue perusing /r/webdev, but hopefully this clears up some things that some of the beginners have! I’m also always happy to answer questions either via PM (I’m /u/gmemstr on reddit) and I can be reached via email - gabriel at gitgalaxy dot com.
Written on August 25th, 2018 by Gabriel Simmer (@gmem_)