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.
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_)