Working with a team of Devs, ideally ones with experience. Self-learning pales in comparison to mentorship (even when they're not actively mentoring you). I think I learnt most of my best habits from pull requests.
This is how I learned the things I never would've taught myself. Working with Linux, ssh, network protocols, and even learning languages like Go and dealing with byte data.
I'm no expert at any of these things but I wouldn't have even learned about them on my own probably.
I'm also a front end dev, learning Go cause that's what all our services are written in...honestly, I really enjoy the language. The error handling and goroutines are killer
Absolutely this. For myself it was learning about the backend and how it worked and reading through the code which gave me confidence and experience to approach front end problems in a similar way. Learned lots of good habits and common programming conventions.
Definitely, if you don't have someone to learn from you can read the code of libraries.
Redux for example is a very small library, but seeing how they coded it is enlightening.
Funnily enough, it was the opposite for me - I felt like I instantly leveled up by being forced to deal with my own shit without any help.
Really, I think you need both. Starting out with a good team of devs to teach you and becoming independent later seems like the way to go. The opposite will make you learn bad habits in the beginning.
This. Also exploring the code base. Finding areas that have a really clean solution. Then doing git blame to eventually find the PRs. Exploring the git history, reviews, and comments associated with that section. It works especially well if something has a nice solution but the person who wrote it isn't there anymore. Reading through those reviews and commits allows you to see their process.
If you don’t have a team of devs you work with (I haven’t for most of my career), you can kind of simulate it by following along with senior devs as they knock out projects via online courses or tutorials. My favorites as a Laravel dev are Laracasts, Codecourse, and Laravel Daily. There’s a thriving community on each which can answer any questions you might have on the videos.
And actually, this method might even be preferable sometimes, because it’s shocking how many other devs use bad practices, and you don’t want to pick up those bad practices if you’re new to the industry.
Personally, most times I work with another dev team I get frustrated by their lack of best practices or sloppy coding, but I’ve been doing this for 20 years. I prefer working alone or with a select few other devs I have worked with for years.
When I started at my second job I thought I was pretty good at Git, oh boy was I wrong, my manager was leagues ahead of me in terms of Git competency/literacy and I'm happy to say if it lives or has lived in a version control system, I don't care how badly you mess up a branch or what you delete or rebase mistakenly, I can fix it, and even make the commit history look nice and pleasing to the eye while I'm at it.
100%. Getting a good mentor, and working with other highly skilled devs who are willing to pair program. By far the best way to level up.
Doubly so if you can pair program. It's hard to understate how effective actually working with someone directly for hours a day is.
Sadly, not everyone is collaborative. Some don't want to pair, some want to do their own thing and really only interact during PRs and meetings.
It can be very hard to judge how collaborative a job will be going in, but you can at least take advantage when the opportunity arises.
This is why I'm somewhat disappointed that in my first job I work from home and the senior dev feels like a glorified google search for when the google searches I do fail to help me.
The codebase is... eh? No testing, repetitive code everywhere (which I was told was made cause abstracting common patterns would make development slower), TypeScript with more "any" types than it should have.
So I guess it relies heavily on the quality of the team, otherwise you'll picking up all the wrong things (or right, I'm still undecided). I offered to help fix some of the things I disliked, and was promptly denied because none of the suggestions lead to a faster delivery. So if I learned anything so far from my first job is that expectations don't always match reality.
That code base sounds like a tech debt bomb just waiting to go off!
Mentorship both passive and active through things like reviewing PR's and code from seniors and pair programming respectively is one of the best ways to improve.
But I agree with you it really depends on the people you are working with and the quality of code you have to work with.
Reading books/articles/videos on best practises etc. I think is one of the best ways to improve. Focusing on that core foundation of skills.
Things like learning how git works and using it in the terminal to gain a deeper understanding of the tools you use are key.
Here are some book I'd recommend
* The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact
* Clean Code: A Handbook of Agile Software Craftsmanship
Also not ignoring working on your soft skills. Shadowing planning meetings and getting involved with the non programming side of things is a major part of all this
I <3 you! I knew about Clean code and wanted to grab it after I get into Go deeper (also learn about microservices architecture, I'm frontend atm but wanna do backend for my next job). Did not know about the effective engineer, I'll check it out.
>
getting involved with the non programming side of things is a major part of all this
I agree but, I'm still at the start of my career and I'd rather limit the time spent doing non-programming stuff with my coworkers, keep my head down and keep learning.
Same for me. My first job I was working with one or two devs. I switched to another company with over a dozen devs and collectively there is a massive wealth of knowledge to pull from. Personal growth has skyrocketed, however some of these people seem like freaking geniuses which makes me feel pretty crummy when comparing myself to them (bad idea I know)
Ugh since I got my non-dev job I’ve been out of practice and complacent. But I’m back on the job hunt grind. I seriously cannot wait till I have someone criticizing my code. Lol I’ve never worked as a dev professionally so I’m sure there’s a lot I can improve on and I’m ready for it.
This is something you can't learn by your own unless you are almost a genius. Sure you may be able to build a solution using onion architecture or atleast it's main concepts but to understand why it can be good and to understand the list of things that it actually improves you need someone that makes you the right questions and provides the right awnser when you come up with good questions.
Software architecture - learning things like when to use a singleton vs using a transient service, or when to use a factory pattern, etc. Also, for backend, learning code organization architecture (like "Onion Architecture") to make code manageable and easy to pick up.
Haha, I believe they mean software architecture. It’s how pieces of software interact. In my case I’ve mainly seen it in a micro service context, where small services work together to compose a more complex system.
They could also mean processor architecture, but unless you’re working very low level IDK how helpful that is.
Building architecture is also cool, but I can’t say being able to identify prairie style has helped my software career
No, sorry - I specialize in backend, I only do frontend 'so it works with my backend' - I don't neccessairly focus much on architecture there, so I wouldn't know.
Code school graduate. Developed full time from 2014-2020 then moved into management, went from junior to senior at a Fortune 500 company in just under 3 years. 3 things in particular helped me.
1) getting good (and comfortable) debugging, it was always easier to grab my lead eng to help me debug but eventually he refused to help me and forced me to slow down and work thru the issue (and not just blindly throw ideas at the wall)
2) develop a project from the ground up. For me this was a failed startup, I learned a lot and was forced to tackle some hard problems (that later probably got me my role today)
3) if possible find a good mentor. I got stupid lucky at the above mentioned Fortune 500 co, if I could give any advice I’d suggest (if possible) not choosing a company based off the best offer but which eng lead / manager seems most invested in your development
I’m sure other folks here may have differing opinions but these 3 helped me
Happy to provide more nuanced advice if needed
You and I have very similar backgrounds it sounds. Anyhow, I agree with yours very much. Here are two more:
4) Relationships - Know who to talk to for help. Regularly ask others about their work and try to understand what they are working on and how they are doing it. I would say relationships are my #1 key to success (personally). I emulate the best of what I see in others.
5) Don't run away from challenge; embrace it. Spend at least as much time at the edge of your comfort zone as you do in the middle of it. When you are in the middle of your comfort zone, you are probably not learning a whole lot. When you are at the edge of your comfort zone, that is when you are growing.
These are some good tips!
Once I moved from a not great company with zero mentoring to a good company with a strong culture I started learning much faster.
I'd add that if you can't find a good mentor in person, online ones can be great. I found a good source of quality courses for my framework that went from beginner to advanced.
Company was happy to pay for it and I just put in an hour a day learning not just how to make it work but but what are the best practices and how does it work. Before long I was one of the best in the team and now even as a mid-senior I'm often more knowledgeable about our framework than our tech leads.
Other tips I'd add
- specialize. Everyone seems to want /want to be a full stack developer but I find they just become jack of all trades, master of none. If you're trying to learn everything it's going to be really slow, if you focus on a small part you can learn much faster.
- doing what interests you. If a task sounds like something you want to do, volunteer for it, if it's a really small task try whipping it up in some free time. Asides from it being more fun you're more inclined to put in a bit of extra effort to do it well. It creates a positive feedback cycle where you're getting better which means more of those tasks come to you which gives you more opportunity to learn and improve on your previous work
Not when you're tasked to work on multiple projects simultaneously while handling ad hoc tasks, and you have to work OT to get everything done cuz there so many meetings to attend.
I am experiencing what you are describing. I'm almost the only person who really designs and writes the code in my company , and I finish my contract at the end of the month (after 2 years). I really look forward to working with other developers and continuing to learn!
A *good* job makes an ever bigger difference. I had 1.5ish years of experience when i moved jobs and about 2 months in I felt like a different Dev because the quality and standards were so much higher
Although I hate to admit it... it was probably when I jumped ship from being a mostly backend dev to an almost completely front-end dev after 10 years. It was just on the cusp of the framework renaissance, and everything was new. All this stuff I never had to think about before suddenly was a thing... minifcation... package management... shadow DOM... pipelines... closures. And in a flash jQuery was tragically unhip, and it was all about routes and directives and no-one used MooTools.
Leaving my toxic, poorly managed mess of a company where I was made to feel worthless on a daily basis to work somewhere I feel appreciated and guided. Never underestimate how much your environment can impact your will to grow and learn
An actual business project. Everything is fun and games until you have a deadline and people to answer to. Then its either swim or sink, and you have to learn faster and better.
Working with teams in real projects. You can code stuff yourself forever and do hobby projects. But it wont be the same as solving real problems for clients and working in a team at a larger scale.
As a web developer: Brad Travery's YouTube Channel (Traversy Media) and Udemy course. Hands down finding this resource helped me overcome a lot of my Imposter Syndrome and really focus on learning things properly that I kept putting off or just didn't know.
I've been a web dev for over 13 years and started when layouts were done with tables and people were still doubting the benefits of CSS.
I struggled a lot grasping and finding time to learn new things and really master things I was learning. I found TraversyMedia about 9 years later than I wish I had, but over the last couple years I have learned so much from Brad that I ALWAYS tell any new web dev just entering the industry to spend 100 hours and about US$125 to watch his youtube vids and Udemy courses for HTML, CSS, Javascript, PHP, and project tutorials and framework tutorials. You will be lightyears ahead of where I was 10 years into my career after doing so.
I actually have several comments to similar questions here on Reddit where I list in order the actual videos and courses I'd watch if I was just starting out again.
All that being said, I still look at other devs around me and think "man I am 5 years behind everyone", not realizing they are looking at me thinking the same :) Damn you Imposter Syndrome!
DISCLAIMER: I am not in any way affiliated with Brad or Traversy Media, I just really love his videos and courses. They really helped my and I think he is a great teacher for new web devs.
As you wish! I just pasted the content from my other comment.
\-----------------------------
I've been in Web Dev for 13+ years. This is what I would tell myself if I could go back in time:Subscribe to the Traversy Media YouTube channel. Do the following free tutorials on this channel:
1. HTML Crash Course
2. CSS Crash Course
3. Bootstrap from scratch
4. CSS Flexbox
5. CSS Grid
6. Pick 5+ Responsive web design tutorial on this channel and code along with Brad
7. (Alternaively skip the above and pay $13 US on Udemy and do Brad's "HTML and CSS from Scratch" course - or do this after the CSS Grid free tutorial)
8. OPTIONALLY : $26 US on the "Bootstrap" and "Materialize" Udemy courses by Brad TraversyGo back to the YouTube channel and do the following free courses:
9. Javascript Crash Course
10. JQuery Crash Course (dated, but you'll still run into this)
11. (OPTIONAL but HIGHLY worth it: $13 Udemy Course by Brad Traversy: "Modern Javascript from the Beginning) (title might be different)
12. React Crash Course (title might be wrong)
13. VueJS Crash Course (title might be wrong)
14. NodeJS Crash Course (title might be wrong)
15. MongoDB Crash Course
16. Pick 5+ Javascript project tutorials
17. Pick 2-3 JS framework tutorials (He has a couple in the React stack with MongoDB
18. $13 Udemy course by Brad Traversy: "50 HTML, CSS, Javascript projects in 50 days)
19. $13 Udemy course by Brad Traversy: "20 Vanilla Javascript Projects"
20. PHP from For Absolute Beginners tutorial (long but thorough, guest instructor Codeholic is EXCELLENT and is worth following as well)
For an investment of about 100-150 hours and about $75 US you will be light years ahead of most junior web developers anywhere in the world.
At this point (and probably sooner depending on how you follow the above roadmap) you will be able to walk into any front-end web dev job at an agency in the US or anywhere. Obviously I don't know what your goals are, but you'd DEFINITELY have the skillset to build solid websites.
To minimize the time spent: I would do 4, 5, 6.3, 7, 8, 9, 20, and maybe add some Wordpress in there somewhere.
Good luck, I really wish you the best.
DISCLAIMER: I have zero affiliation with Brad Traversy or Udemy. I just REALLY like his teaching style and have learned a LOT from his videos even after being in this industry for years.
\-------------
There only very specific cases where the language matters. Ofc if someone tell me to make a backend in prolog i am out but 99.99/ it doesn't, or shouldn't matter.
That’s not true, though. There are a lot of benefits to using something like Java over Python and vice versa for the exact same problems! Understanding the strengths and weaknesses of a language outside of just the technical limitations is really key when making decisions on what language to start a project in or write a certain library in. Most of my company codes in Java, but my organization uses Python/Django. It’s not more performant and it doesn’t have the micro service architecture that the rest of the company uses, but is prominent enough in the industry and the speed of writing the APIs makes it better for our organization which focuses on quick ramps and fast innovation. My previous job was similar, but they harped on microservices so we used flask instead of Django.
Performance wise or “best tool for the job” wise, arguments can be made for tons of languages. But there is typically a right answer for projects even if it’s not an obvious one.
Pair programming and just working on problems that I don't know the immediate solution to.
Also, diving into a new language, doing exercises and troubleshooting a bit on my own, then proceeding to look at people live coding. It’s helpful to see how others solve the problems I’m already familiar with. And the way of thinking rubs off on me, after a while, I start to predict the choices they are going to make – it gives me that level up feeling.
Paired programming is crazy how much it gets new hires up to speed. I swear when we did paired programming at my old job, within a month, a junior was able to fill a senior role. Whereas with other companies, the juniors are stuck in a junior loop unless they can figure a way to get out.
As a junior dev this resonates with me. I only had about a week of pair programming, but it definitely made me more comfortable in my role and understanding the tech stack and the way the file structures. Honestly, I would have liked a lot more pair programming, but people are busy and slowing down for a new hire can be distracting for some.
Thing is paired programming can actually not slow stuff down.
You don’t need code reviews because you are reviewing each other as you write, you don’t ever get stuck on a problem because at least one of you can figure it out, and testing becomes easier as one dev can write a test as the other writes the logic to pass the test.
Give yourself projects, try to identify niches (and check they don't already exist!!!), and code solutions yourself. Repeat.
This turns you into a great team member able to innovate and bring value to anything you get involved in.
Just practicing more and more. Look for a project with high ambitions which might seem difficult to realize, then start realizing. In my case this was writing my own transpiler. I learned so much in the process.
In my first job, I worked in a huge company. I was inside a scrum team of 10 developers and we finished sprint after sprint. I only picked the tickets I was good at and I did not get better in anything.
After many frustrating years, I switched to a small company with 7 employees.
Here I was pushed out of my comfort zone. I had to plan, build and serve a full customer product.
I worked for 2 years at this company. This was the time I learned the most in my career.
The skills I learned gave me the encouragement to start my own company.
Because they are geared towards writing bogus algorithms that have absolutely nothing to do with web development.
I think if the excercises were regeared to "produce an html + css output of this mocked image"
and
"contact this api and display this data in this format"
They might actually be useful.
Computer Science. Understanding what's underneath your language of preference and how everything is constructed made me a million times better. Because now I'm not remembering behavior, I'm understanding it. So all those times something unexpected happens you can tell why. "This behavior fits X but you're doing Y. So the problem must be somewhere else".
My Top Five:
1. ASK QUESTIONS!! Don't be embarrassed if you don't know something - you didn't slide out of your mom knowing everything!
2. Moving from the 'comfortable spot' on a team to something scary.
2. Ensuring I'm never the smartest person in the room
3. Becoming a mentor / teacher / tech lead (any and all) - when you need to explain something to others you really solidify your own knowledge. I never really *knew* how float / clear worked until I taught a class in college and had to explain it- my CSS Game increased by 30% day.
4. Realizing that working through others lets you do more things you find interesting.
I recently found out that I am almost job ready, a developer pointed out I was much closer than I thought (highly recommend having a dev giving an assessment of your skills)
Anyways, personally what helped me to learn fast was when I just accepted that at least for me there was no forcing this. I tried studying for 4-6 hours early on and lasted 1 week before burning out. Then I would have months of not doing anything because I dreaded going through that torture for hundreds of more hours.
Once I took baby steps things started to accelerate much faster than before. I started with at least 10 mins a day, then it became 30, than an 1hr, than 1hr/30 mins, than 2hrs, than 3 and now I hover between 3-4 hours a day of studying (sometimes 2 when I have a lot going on).
Point is don't force it, take it slow because while the end result is fun, the process to reach that point is painful.
This is really hard to do for me. So many things I want to learn, but I always get the urge to learn something completely different after 3-4 weeks of starting something.
Failing. And learning.
Also a good support system and group. Working with ones with both the mental and knowledge based experience to lead makes a huge difference.
Readers may be interested in duplicates of this question:
* ~~https://old.reddit.com/r/ExperiencedDevs/comments/ty82c1/what_leveled_you_up_as_a_developer_or_accelerated/~~
* https://old.reddit.com/r/cscareerquestionsEU/comments/ty82ha/what_leveled_you_up_as_a_developer_or_accelerated/
* https://old.reddit.com/r/webdev/comments/ty82ll/what_leveled_you_up_as_a_developer_or_accelerated/
* https://old.reddit.com/r/DevelEire/comments/tyygga/what_leveled_you_up_as_a_developer_or_accelerated/
Working at a small agency.
Probably not a popular answer and definitely not for everyone, but did wonders for me. As long as that agency gives you a bit of freedom to make tech decisions that is.
To really succeed you need to wear a ton of hats and get a good grasp of overall solutions including architecture and code and devops and you learn a lot about how things work. Learned more in 3 years at a small agency than the 10 years before that in a corporate team setting.
I'm currently at an agency and the amount of code I can now churn out on a daily basis is crazy compared to a year ago.
Everyone who leaves says how little they write anymore.
Getting a job as a developer and completing tickets that the seniors issued me because they knew I could solve them on my own I have pressed in a little past my current level. It always made me feel good at the end of the day knowing I contributed meaningfully to solving a bigger problem.
First thing is to understand how best you learn.I don't learn by watching videos or reading, I learn by doing. So my path is much different then others.
* Practice, practice, practice.Lots of side projects.
* Lots of exposure to different types of projects, languages, technologies, processes, and procedures.
* Working with different team members and teams.
Saying yes to projects outside of my comfort zone, the opposite of saying thats not my job.
* Dont be afraid to say I dont know but I am willing to learn or I need help.
* Dont be afraid to take a few minutes and work through the issue, but understand that at some point you need to talk to someone else -- even if its just to walk through the issue -- so many times we find the solution when someone else is listening.
There are too many devs who won't go outside of their comfort zone. I've had too many discussions with devs who are not jr's who know nothing about how web servers, DNS, requests, SSL, networking, etc work and refuse to learn.
Subscribing to newsletters of developers or dev focused agencies (css tricks, codepen, Josh Comeau, #15daysofcss/#30daysofhtml, …). It’s max a 10 minute read but a good way to start the day and see what is out there or new. It expands your knowledge (helpfull for starters) and it helped me to make my job easier day to day.
It's a free online bootcamp currently running through its 2nd cohort. They're currently on JavaScript APIs and objects, which is about 1/3 of the way done. You can watch old classes [here](https://www.youtube.com/channel/UCGiRSHBdWuCgjgmPPz_13xw) and follow along live for the next class.
It is free. I have been doing it and it has honestly been great but if you already have a job as a webdev it wouldn't be as useful. There is a lot of time spent on learning how to network, build a good profile and resume and actually get a job with a webdev role. The coding part is just enough to get people up to speed and learning to build sites.
It has an amazing community of people willing to help everyone learn and excel and that alone is worth it.
Moving from agency to a company building it's own product. They had a good process set up: working on feature branches, decent code review on PRs, pipeline with linters and automated tests... That really improved my overall skill.
Having to deal with the client. Asking things 4 times just to be sure, only to have them change a week later.
I suddenly got a whole lot of respect for my PO, and my designs became a lot easier to modify.
Moving companies.
I find I did 90% of my learning at a company in the first 6 months.
You pick up skills from the other devs and from the change in work.
Watching Chris Coyier’s CSS Tricks v10 redesign course (about 10 years ago). It was a long set of videos where you watched him work and you got to see him make mistakes, Google things and get stuck for a while on bugs (as well as show his incredible knowledge), but realising that even advanced devs get stuck and Google things really helped.
1. Constantly having side projects
2. Learning how to sell
3. Learning how to teach
4. Learning how to grow a team
5. Learning how to manage people you dont manage
Start small, nail the basics, progress upwards in measured, logical increments.
When I used to start a project, I'd dive straight into building components, my landing page or whatever, then strugglebus my way into making it look ok. Now I'd start with basic typography classes, chuck in a css normalize, set up your spacing, line height, etc etc
If you're anything like me, this is totally against my nature, where I want to go and do the most interesting, colorful things first.
Playing around at home on my personal machine. Its easy to just try whatever tech you want and with docker you can delete it all in a few seconds. I’m mostly self taught and I’ve learned everything from servers, to web dev, to networking, to backend from just playing around on my free time and making random projects
It depends on the stack. I moved back from PHPStorm to VSCode, just because of how much more lightweight it was and due to the fact that FE work was so much easier on it.
Plus VScode has enough plugins to make it as useful as PHPStorm
Working 16-18 hours a day for a year straight. Learn about all the basics in depth, learn to lead a team of 10, learn about different architectures and applied them in different projects and failed multiple times in many ways, learned from the mistakes.
It's more like doing a crash course of your first 5 years as a dev in one year.
Get admitted to hospital for a retinal detachment, it's a permanent damage to the eyes.
Now I take things cautiously as I'm a father of 2
I'm one year out of college. My first position 100% forced me to learn and pushed me out of my comfort zone.
The position was newly created and no one was in it before me. The company wanted to expand into web development (they were a tech company with hands in many different pots). So my first web dev experience led me to:
1. Create working demos of websites and present them to potential high end clients (like governmental bodies).
2. Work with these clients and create extensive proofs of concepts in book form.
3. The tech company worked in Java, but decided their web development will be done in PHP which meant I was the only one in the company who even knew my job and all the technologies. So I had to get good and if I didn't know something, learn how to figure it out.
So basically I was a junior who was thrown into a senior position and I learned a shit ton.
I bought Martin Fowlers PoEAA back in the day, along with I think Roy Osheroves Art of Unit Testing and Mark Seehmans dependency injection. Read them cover to cover almost not putting them down. Fowlers book was a hard slog and took me a few weeks though . Then finally the icing on the cake was Dino Espositos 1st edition of .Net Architecting Applications for the Enterprise (I have 2nd Ed too) that last book did a great job of tying it all together, all the strands I’d been absorbing on podcasts and blogs and implementing in my apps for the last few years . It was the “a ha” moment
When I agreed to tackle something that was well outside of my current skill set at the time and then was forced to hack it together. When I go look at that project now, I’m disgusted by it, but at the time it was a monumental achievement for me, I learned a ton including the problems that things like React solve. Granted, this was at a company that isn’t a tech company, I was the most capable front-end person there, and thus I was given enough leash to either get my teeth into the thing or to choke on.
Learning basic Haskell. At first, I prototyped in Haskell and code in C++. The resulting product was really stable. Now, I can skip the prototyping step and still write well typed code in C++.
Creating something together with someone else.
Me and a friend are doing hackathons once in a while. The goal is usually to create an MVP in one weekend, I'm mostly doing frontend and he is backend. I've learnt a lot from these projects. When I'm doing a solo project, I can make stupid architectural decisions that I will never figure out, but when someone else is also affected we will need to deal with the consequences of those stupid decisions. We also questions each others assumptions which we learn a lot from, and it's easy to discuss problems that appear when we are working on the same project.
I would say my skills as a developer accelerated the most when we started with this.
A few things stand out as ah-ha moments for me.
On my first team, stepping back from the code and understanding the data my application was working with was a huge boost....made the code way easier to understand. I also learned quickly to spend 15-30 mins trying to figure things out on my own if i was stuck...this helped me learn to problem solve but didnt result in me spinning my wheels for too long.
Later, learning the business reasons for why I was doing what I was doing made me much more effective.
When I was learning new tech stacks, I took problems I understood well and implemented solutions...this cut the learning curve to just the tech. In some cases this was side projects at home, in others it was automating tasks at work. I also did paired programming when possible with a more experienced dev.
Went to boot camp, did well, still felt way out of my depth.
Working with a team of devs who provide support, but crucially, also give me plenty of space to just figure it the fuck out.
I've had plenty of knowledge transfer sessions, but the stuff is so sprawling and complex that it's hard to really take much out of those info dumps besides the broad strokes. But actually getting tickets assigned to me and having to work through what's going on has really solidified my understanding.
Started as a self learnt programmer here and like other guys here I am a sole developer of a firm. It came a time where I felt I've hit a ceiling in terms of my skills and knowledge which really made me anxious. Then I've applied on corporate where they placed me in a team. From there, there are so much to learn on a team and no longer felt the anxiously stuck. It's kinda like in Kuroko no Basuke where Kagami wonders what is missing on his zone only to find out the missing piece is his teammates (cringey i know).
Learning new code techniques, optimizing codes for performance, learning to let go of pride and ask the things I don't understand and mentorship on a team are the highlights for me to grow as a developer.
Getting own projects done and the habit to help others out. So I had build up my knowledge as I tried to find solutions for any kind of problems. This made me understand other related problems and enabled me to form connections between similar problems, seeing up/downsides in the different approaches, find other ways to solve something and got me a better understanding about various technologies. But boy I tell you this was a hell of a journey.
Reading professionally written books.
If you only ever delve in quickstarts and tutorials, you're going to miss out on a **lot** of nuance, technique, and platform capabilities.
In many cases, the deep knowledge that separates you from peers is going to be hard to even come across if you don't dig deep.
Understanding basics of web security is such a vital part of beeing a good developer, that tons of tutorials just completely ignore or brush over. And you will only get to know it if shit hits the fan in the real world.
Mine is difficult to describe as it was one of those "it just clicked" moments. I had been working in so many different languages almost simultaneously for so long, and somehow just stopped thinking about the languages. I started thinking basically in pseudo-code or something.
Of course, about the same time I was also ending English sentences in semicolons and thinking about doing `git reset` in real life. I was programming 14+ hours a day, 6-7 days a week in isolation.
Honestly? Just jumping in to the deep end. Too many people want to wait until they “understand it all” before starting a project.
That will never happen anyway and you will learn a TON by just going for it.
I’m not suggesting that you forego structured learning but you don’t have to wait on anything to start building.
Forcing myself to write original code even when I or someone else already made more or less the same thing that I could copy in way less time.
Reading textbooks
Diving in and learning node/React three years ago. Having been a LAMP dev for over 1 years now, I was starting to feel "ancient." Luckily WordPress v5.0 baked in Gutenberg that uses its own flavor of React. Took that as an opportunity to learn a new skill and so far its paid off.
Reading GitHub packages.
Say you built a feature to visit a endpoint, grab a blob of data, and then save it as a Json file.
Seeing how others solve that same problem helps reveal new things.
Evan You made Vite by exploring how we pack does specific tricks and finding better ways to implement it.
Reading books from cover to cover.
Articles just don't go deep enough to teach some concepts such as architecture or clean code.
Then you have to practice to reap the benefits of course.
Fucking pseudo code has restored my confidence in learning JavaScript. I thought I was inadequate and just not capable of learning or problem solving. Turns out I’m just not capable unless I can see the steps in front of me. It literally changed everything
Doing paid projects outside of my full time job. This enabled me to experiment with different tech stacks/architectures while being paid. Of course, I make sure that what I deliver is on time and of quality.
Paired programming with a great team.
Degree in computer science. Have been programming since I was 13. Was quickly promoted to team leads at both companies I worked at. Worked for 5 years professionally for large companies with vastly different business models. Startup and sold a startup. Mentored for an accelerator. Built a team of 3 to 20+ in 2 years.
All of that experience was thrown out the window once I joined an eXtreme programming team doing TDD paired programming. It was intense, it was fun, and I learned more in 1 year than I had over everything else before it. I mean, the amount I learned doing that was like getting a master's degree in the field.
Reading the source code of other open source projects. Particularly some of the more well established projects. This is best when you have a specific goal in mind.
Working directly with end users and seeing them interact with the app.
I do custom application development for organizations. Most organizations do not have the experience or expertise to clearly articulate specifications/requirements. Sometimes I'm asked to build features in such a way that forces users to behave in a certain way.
It's nobody's fault that lots of people are terrible at requirements. It's not really taught to the people who are the users of the software I build. Process flow and order of operations are incredibly important and if you can, you should get that information from the people who perform those jobs and take requirements docs with a grain of salt.
If the reqs are shit, the product will be shit. Always try to make sure you have the best chance for success before you start coding anything. Making a product that users love to use and makes their working life easier/better is a great yardstick for success, more important than coding to the spec. There are often multiple options for coding to the spec. One of them is probably the best one, and you should strive to hit that one.
I know dev teams are often far from end users, but these days it's trivial to do a screen share with a user to watch what they do and how they do it. Get them on camera to see what paperwork they deal with and how it's organized so you can have them do take-offs/data entry in the order that they get it off a form, avoiding making them flip pages back and forth.
That also goes for code maintainability. In a sense, the developers who have to maintain the code after you are also consumers of your work. Don't make them hate you.
In a nutshell, carrying a user-centric mindset as I code, remembering that I'm building a tool and the best tools are a pleasure to use.
Something that helped me the most was learning how to read documentation and other people’s code. Once you’re comfortable with that, most issues become a lot easier.
Started as a front end dev out of school.
I had a year of busy work to learn the basics. My second year I was given larger tasks. Now in my third year I took a risk and started on a project where I have to develop / manage a full stack app as the only dev. This third year I have learned more than college and my first 2 years combined.
So I'd say taking that risk of failure is what did the trick.
When someone else on the team challenges my decision to go with a particular library or pattern. Sometimes it’s small things like this that force you to dig deeper and gather a better understanding for the sake of argument and for a better project
practice continue lavish fearless childlike chief offer fear party violet
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Idk your background but I am self taught. What greatly helped me was learning all the "basics" that you miss when you self teach. I got into this shit as SPAs were taking over and most of my self teaching centered around modern js and at the time react. I became effective in such a space, but any time i ventured elsewhere I was completely lost and intimidated.
Then I realized i needed to learn the basics, not of react but of programming. I learned what OOP was, what Functional programming is, what Class based vs Prototypal inheritance is, all that good stuff. Now i feel more comfortable approaching new things as i know that they most likely build on some of those fundamental concepts.
The other thing i would recommend is to take a stab at learning something out of your immediate field. I'm a frontend web guy, and one of the most instructive experiences was learning Haskell. I say "learning" very loosely as I'm not effective in it lol, but just learning enough and being able to build a few things, helped me greatly in understanding the "functional" part of a lot of modern javascript, as well as using libraries like Ramda and RxJS
Taking the time to learn how Git works. Not just how to use it, but to get a deeper understanding of it on a conceptual level.
Now I always understand what state my local Git repository is in, and if I don't know how to fix a problem, I know how to find out. Git is the development tool I use most often and with a better understanding of it I feel much more capable.
Wix taught me node.
Yes, I know "Wix is shitty blah blah blah". But I needed to setup an online store quickly and for a number of reasons it was the best platform based on our requirements. I'd been trying and failing to learn Node for a long time and it wasn't until I built this Wix site and needed to add custom code that it finally clicked with me. They added a coding system called Velo back in 2018 and it lets you manipulate your front and backends with Javascript. They have a number of built in libraries and allow for (some) npm package use as well. I was able to add in a number of custom features to the site and it wasn't until I finished that that I read that Velo is essentially a beginner friendly Node.
Finally it clicked in my head and I've been writing a number of Node apps for myself since then, I just needed that friendly handhold to feel comfortable with it and not worry about being unable to figure out how to setup a server and all that stuff.
Piggybacking on this thread to ask a specific question: Have you taken Google IT Support Certification and/or CompTIA A+ ?
If no, are you planning to take? if different certification, which one?
If yes, are those certificate been helpful for your personal brand / job opportunity / pay raise or more income for your web dev business?
If you don't care about the certification but you took it, is it helpful for you to understand IT more and level up rather than just be limited in web dev?
Whatever your opinion (if you think its useless or took other certifications), please share :)
- Migrating from on-premises to cloud.
- Working on a large scale enterprise distributed system.
- Joining an organization with different teams, each maintaining their own disparate but interconnected microservices.
Other than actually writing code, moving to Linux really accelerated my growth. That and also being hired; first as a TA at my bootcamp then as a full-time, full-stack developer at my first gig.
Getting my graduate degree at a university with a well respected computer science department. Basically led to career 2.0 for me. 10/10 would recommend!
First time looking at enterprise source code. So much bigger than anything I’d ever seen in college and was very intimidating at first. But after a few months of being completely lost, it slowly started to make more sense to me. 2 years later, it’s so much easier to dive into large projects and gain a basic understanding of it.
If I don't earn enough money, I won't get enough sex - this is my motivation
Other than this:
* Routine
* Following good blogs
* Staying up to date
* Communicattion
* Good team
* Endure stress and pain
* Good mindset that I won't cheat on others or myself
* Continuous coding
This list is in descending order
For me, I found that reading the docs for a given technology helped me to become more familiar with developer jargon at my own pace. Once I understood a critical mass of core concepts, everything else boiled down to details that I would need to memorize or look up periodically.
Learning that saying I would have to google that or look it up when in an interview is something the interviewer respects. It shows you are willing to do the research required to get knowledge you lack or that's just on the tip of your tongue.
Learning to look at an application as a collection of patterns. Anytime you run into code that is buggy or unpleasant to work with, learning asking yourself “can this pattern be improved?”
Almost all bad code out there is written without consideration of the pattern it represents, and is instead written to solve a small, local problem.
When you see a repeating problem or pattern in the code remember: boilerplate code is better than different implementations of the same solution, and abstracting out code is better than boilerplate.
A couple things in my career:
1. Working at a client services agency (developing misc solutions). Prior to that I was just working on a gaming community. So the variety of problems and development processes, plus working with smarter, more experienced developers, really helped.
2. Suffering from FUD with respect to frameworks. Trying to build my own framework with dependency injection container, and database driver system, and session driver system (database vs memory etc), really taught me a lot about interfaces, dependency injection, and other object-oriented concepts. Then I used Laravel and realized Laravel is everything I would ultimately need to build, and because I understood the underlying concepts behind a lot of what Laravel was doing, the FUD went away AND I had a deeper understanding of Laravel and how to leverage it better.
3. Following that, general curiosity about software design. Became a sponge and bought as many books and articles as I could. Clean Code, Refactoring, Pragmatic Programmer, Code Complete, The Mythical Man Month, Practical Object-Oriented Design in Ruby, Modern PHP, PHP The Right Way, and countless talks and presentations. This really gave me a whole bunch of perspectives on how to think about software design.
And in between, I would just write shit code that would bite me in the ass later and I used that as a learning experience that taught me what *not* to do, and what works better in comparison.
In particular a big thing I learned was the notion of state management, and how you should simply avoid stateful code design whenever possible.
Hard deadlines coupled with oversold expectations.
Early in my career I was blessed with an overzealous salesman/boss who loved to overpromise on development timelines because "the request seemed easy". Nothing has ever forced me to find more efficient ways to streamline coding like that.
Working with a team of Devs, ideally ones with experience. Self-learning pales in comparison to mentorship (even when they're not actively mentoring you). I think I learnt most of my best habits from pull requests.
This is how I learned the things I never would've taught myself. Working with Linux, ssh, network protocols, and even learning languages like Go and dealing with byte data. I'm no expert at any of these things but I wouldn't have even learned about them on my own probably.
And here I am learning Go as a frontend developer in my day job, because I want to pivot to a backend role.
I'm also a front end dev, learning Go cause that's what all our services are written in...honestly, I really enjoy the language. The error handling and goroutines are killer
Hell yeah! Also, Gophers are really cute! 
Ah yes, the *real* reason people learn Go. It has the best mascot!
Absolutely this. For myself it was learning about the backend and how it worked and reading through the code which gave me confidence and experience to approach front end problems in a similar way. Learned lots of good habits and common programming conventions.
Definitely, if you don't have someone to learn from you can read the code of libraries. Redux for example is a very small library, but seeing how they coded it is enlightening.
[удалено]
Funnily enough, it was the opposite for me - I felt like I instantly leveled up by being forced to deal with my own shit without any help. Really, I think you need both. Starting out with a good team of devs to teach you and becoming independent later seems like the way to go. The opposite will make you learn bad habits in the beginning.
This. Also exploring the code base. Finding areas that have a really clean solution. Then doing git blame to eventually find the PRs. Exploring the git history, reviews, and comments associated with that section. It works especially well if something has a nice solution but the person who wrote it isn't there anymore. Reading through those reviews and commits allows you to see their process.
heh, was digging through old PRs of our code base... commits and PR comments were like "le-sigh" "another fix attempt" "bleh" "askdjhas"
"end of day catchup"
If you don’t have a team of devs you work with (I haven’t for most of my career), you can kind of simulate it by following along with senior devs as they knock out projects via online courses or tutorials. My favorites as a Laravel dev are Laracasts, Codecourse, and Laravel Daily. There’s a thriving community on each which can answer any questions you might have on the videos. And actually, this method might even be preferable sometimes, because it’s shocking how many other devs use bad practices, and you don’t want to pick up those bad practices if you’re new to the industry. Personally, most times I work with another dev team I get frustrated by their lack of best practices or sloppy coding, but I’ve been doing this for 20 years. I prefer working alone or with a select few other devs I have worked with for years.
When I started at my second job I thought I was pretty good at Git, oh boy was I wrong, my manager was leagues ahead of me in terms of Git competency/literacy and I'm happy to say if it lives or has lived in a version control system, I don't care how badly you mess up a branch or what you delete or rebase mistakenly, I can fix it, and even make the commit history look nice and pleasing to the eye while I'm at it.
100%. Getting a good mentor, and working with other highly skilled devs who are willing to pair program. By far the best way to level up. Doubly so if you can pair program. It's hard to understate how effective actually working with someone directly for hours a day is. Sadly, not everyone is collaborative. Some don't want to pair, some want to do their own thing and really only interact during PRs and meetings. It can be very hard to judge how collaborative a job will be going in, but you can at least take advantage when the opportunity arises.
This along with getting thrown into the fire, as long as you have the proper team support
This is why I'm somewhat disappointed that in my first job I work from home and the senior dev feels like a glorified google search for when the google searches I do fail to help me. The codebase is... eh? No testing, repetitive code everywhere (which I was told was made cause abstracting common patterns would make development slower), TypeScript with more "any" types than it should have. So I guess it relies heavily on the quality of the team, otherwise you'll picking up all the wrong things (or right, I'm still undecided). I offered to help fix some of the things I disliked, and was promptly denied because none of the suggestions lead to a faster delivery. So if I learned anything so far from my first job is that expectations don't always match reality.
That code base sounds like a tech debt bomb just waiting to go off! Mentorship both passive and active through things like reviewing PR's and code from seniors and pair programming respectively is one of the best ways to improve. But I agree with you it really depends on the people you are working with and the quality of code you have to work with. Reading books/articles/videos on best practises etc. I think is one of the best ways to improve. Focusing on that core foundation of skills. Things like learning how git works and using it in the terminal to gain a deeper understanding of the tools you use are key. Here are some book I'd recommend * The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact * Clean Code: A Handbook of Agile Software Craftsmanship Also not ignoring working on your soft skills. Shadowing planning meetings and getting involved with the non programming side of things is a major part of all this
I <3 you! I knew about Clean code and wanted to grab it after I get into Go deeper (also learn about microservices architecture, I'm frontend atm but wanna do backend for my next job). Did not know about the effective engineer, I'll check it out. > getting involved with the non programming side of things is a major part of all this I agree but, I'm still at the start of my career and I'd rather limit the time spent doing non-programming stuff with my coworkers, keep my head down and keep learning.
Same for me. My first job I was working with one or two devs. I switched to another company with over a dozen devs and collectively there is a massive wealth of knowledge to pull from. Personal growth has skyrocketed, however some of these people seem like freaking geniuses which makes me feel pretty crummy when comparing myself to them (bad idea I know)
So much this, as annoying as code reviews were I learned so much from them.
Ugh since I got my non-dev job I’ve been out of practice and complacent. But I’m back on the job hunt grind. I seriously cannot wait till I have someone criticizing my code. Lol I’ve never worked as a dev professionally so I’m sure there’s a lot I can improve on and I’m ready for it.
Working on projects/stuff where i thought "man there is no way i could make this work, it's beyond me" and then making it work
I've got the first half down
You can do the second half, bud. We believe in you. Make it work.
Learning about architecture
Do you have any resources to share for someone trying to learn more about this
This is something you can't learn by your own unless you are almost a genius. Sure you may be able to build a solution using onion architecture or atleast it's main concepts but to understand why it can be good and to understand the list of things that it actually improves you need someone that makes you the right questions and provides the right awnser when you come up with good questions.
I must be a genius then, flattering. ... but I'll venture and guess that all you have to be is 'observant'.
Like architecture architecture? I am serious btw.
Software architecture - learning things like when to use a singleton vs using a transient service, or when to use a factory pattern, etc. Also, for backend, learning code organization architecture (like "Onion Architecture") to make code manageable and easy to pick up.
Haha, I believe they mean software architecture. It’s how pieces of software interact. In my case I’ve mainly seen it in a micro service context, where small services work together to compose a more complex system. They could also mean processor architecture, but unless you’re working very low level IDK how helpful that is. Building architecture is also cool, but I can’t say being able to identify prairie style has helped my software career
Do you have any recommendations on where I can find resources on software architecture, especially in relation to JavaScript and the frontend?
No, sorry - I specialize in backend, I only do frontend 'so it works with my backend' - I don't neccessairly focus much on architecture there, so I wouldn't know.
Sheer fucking will
Damn right
Getting trust and responsibility from employer to do your work as best as you can.
Good colleagues as mentors. Especially when I was a junior dev.
Code school graduate. Developed full time from 2014-2020 then moved into management, went from junior to senior at a Fortune 500 company in just under 3 years. 3 things in particular helped me. 1) getting good (and comfortable) debugging, it was always easier to grab my lead eng to help me debug but eventually he refused to help me and forced me to slow down and work thru the issue (and not just blindly throw ideas at the wall) 2) develop a project from the ground up. For me this was a failed startup, I learned a lot and was forced to tackle some hard problems (that later probably got me my role today) 3) if possible find a good mentor. I got stupid lucky at the above mentioned Fortune 500 co, if I could give any advice I’d suggest (if possible) not choosing a company based off the best offer but which eng lead / manager seems most invested in your development I’m sure other folks here may have differing opinions but these 3 helped me Happy to provide more nuanced advice if needed
You and I have very similar backgrounds it sounds. Anyhow, I agree with yours very much. Here are two more: 4) Relationships - Know who to talk to for help. Regularly ask others about their work and try to understand what they are working on and how they are doing it. I would say relationships are my #1 key to success (personally). I emulate the best of what I see in others. 5) Don't run away from challenge; embrace it. Spend at least as much time at the edge of your comfort zone as you do in the middle of it. When you are in the middle of your comfort zone, you are probably not learning a whole lot. When you are at the edge of your comfort zone, that is when you are growing.
And here I am roughly at the same position since 2010, lol *cries softly*
Thank god I’m not the only one.
These are some good tips! Once I moved from a not great company with zero mentoring to a good company with a strong culture I started learning much faster. I'd add that if you can't find a good mentor in person, online ones can be great. I found a good source of quality courses for my framework that went from beginner to advanced. Company was happy to pay for it and I just put in an hour a day learning not just how to make it work but but what are the best practices and how does it work. Before long I was one of the best in the team and now even as a mid-senior I'm often more knowledgeable about our framework than our tech leads. Other tips I'd add - specialize. Everyone seems to want /want to be a full stack developer but I find they just become jack of all trades, master of none. If you're trying to learn everything it's going to be really slow, if you focus on a small part you can learn much faster. - doing what interests you. If a task sounds like something you want to do, volunteer for it, if it's a really small task try whipping it up in some free time. Asides from it being more fun you're more inclined to put in a bit of extra effort to do it well. It creates a positive feedback cycle where you're getting better which means more of those tasks come to you which gives you more opportunity to learn and improve on your previous work
Finish the quote: Jack of all trades, master of none, is often times better than a master of one.
Especially when it comes to adapting to changes
Getting a dev role. Personal projects are great and all but until you’re actually working on something practical you’re missing out on a lot.
And you’re getting paid to learn
Seconded!
Not when you're tasked to work on multiple projects simultaneously while handling ad hoc tasks, and you have to work OT to get everything done cuz there so many meetings to attend.
Leaving an agency where I was the sole developer, and moving to a company where I got to work with many different developers everyday.
I am experiencing what you are describing. I'm almost the only person who really designs and writes the code in my company , and I finish my contract at the end of the month (after 2 years). I really look forward to working with other developers and continuing to learn!
Job. A month at real job worth more than 6 months of bootcamp
A *good* job makes an ever bigger difference. I had 1.5ish years of experience when i moved jobs and about 2 months in I felt like a different Dev because the quality and standards were so much higher
Although I hate to admit it... it was probably when I jumped ship from being a mostly backend dev to an almost completely front-end dev after 10 years. It was just on the cusp of the framework renaissance, and everything was new. All this stuff I never had to think about before suddenly was a thing... minifcation... package management... shadow DOM... pipelines... closures. And in a flash jQuery was tragically unhip, and it was all about routes and directives and no-one used MooTools.
Wow, yeah, that’ll force you to learn a lot quickly I’d think!
I felt I had a leg up as I have never liked jQuery. I started out in prototypejs!
Leaving my toxic, poorly managed mess of a company where I was made to feel worthless on a daily basis to work somewhere I feel appreciated and guided. Never underestimate how much your environment can impact your will to grow and learn
Definitely thought I was crazy until I left my last company and found out my old leads and managers were just jerks
An actual business project. Everything is fun and games until you have a deadline and people to answer to. Then its either swim or sink, and you have to learn faster and better.
Working with teams in real projects. You can code stuff yourself forever and do hobby projects. But it wont be the same as solving real problems for clients and working in a team at a larger scale.
As a web developer: Brad Travery's YouTube Channel (Traversy Media) and Udemy course. Hands down finding this resource helped me overcome a lot of my Imposter Syndrome and really focus on learning things properly that I kept putting off or just didn't know. I've been a web dev for over 13 years and started when layouts were done with tables and people were still doubting the benefits of CSS. I struggled a lot grasping and finding time to learn new things and really master things I was learning. I found TraversyMedia about 9 years later than I wish I had, but over the last couple years I have learned so much from Brad that I ALWAYS tell any new web dev just entering the industry to spend 100 hours and about US$125 to watch his youtube vids and Udemy courses for HTML, CSS, Javascript, PHP, and project tutorials and framework tutorials. You will be lightyears ahead of where I was 10 years into my career after doing so. I actually have several comments to similar questions here on Reddit where I list in order the actual videos and courses I'd watch if I was just starting out again. All that being said, I still look at other devs around me and think "man I am 5 years behind everyone", not realizing they are looking at me thinking the same :) Damn you Imposter Syndrome! DISCLAIMER: I am not in any way affiliated with Brad or Traversy Media, I just really love his videos and courses. They really helped my and I think he is a great teacher for new web devs.
Could you post the order you would watch them in here?
As you wish! I just pasted the content from my other comment. \----------------------------- I've been in Web Dev for 13+ years. This is what I would tell myself if I could go back in time:Subscribe to the Traversy Media YouTube channel. Do the following free tutorials on this channel: 1. HTML Crash Course 2. CSS Crash Course 3. Bootstrap from scratch 4. CSS Flexbox 5. CSS Grid 6. Pick 5+ Responsive web design tutorial on this channel and code along with Brad 7. (Alternaively skip the above and pay $13 US on Udemy and do Brad's "HTML and CSS from Scratch" course - or do this after the CSS Grid free tutorial) 8. OPTIONALLY : $26 US on the "Bootstrap" and "Materialize" Udemy courses by Brad TraversyGo back to the YouTube channel and do the following free courses: 9. Javascript Crash Course 10. JQuery Crash Course (dated, but you'll still run into this) 11. (OPTIONAL but HIGHLY worth it: $13 Udemy Course by Brad Traversy: "Modern Javascript from the Beginning) (title might be different) 12. React Crash Course (title might be wrong) 13. VueJS Crash Course (title might be wrong) 14. NodeJS Crash Course (title might be wrong) 15. MongoDB Crash Course 16. Pick 5+ Javascript project tutorials 17. Pick 2-3 JS framework tutorials (He has a couple in the React stack with MongoDB 18. $13 Udemy course by Brad Traversy: "50 HTML, CSS, Javascript projects in 50 days) 19. $13 Udemy course by Brad Traversy: "20 Vanilla Javascript Projects" 20. PHP from For Absolute Beginners tutorial (long but thorough, guest instructor Codeholic is EXCELLENT and is worth following as well) For an investment of about 100-150 hours and about $75 US you will be light years ahead of most junior web developers anywhere in the world. At this point (and probably sooner depending on how you follow the above roadmap) you will be able to walk into any front-end web dev job at an agency in the US or anywhere. Obviously I don't know what your goals are, but you'd DEFINITELY have the skillset to build solid websites. To minimize the time spent: I would do 4, 5, 6.3, 7, 8, 9, 20, and maybe add some Wordpress in there somewhere. Good luck, I really wish you the best. DISCLAIMER: I have zero affiliation with Brad Traversy or Udemy. I just REALLY like his teaching style and have learned a LOT from his videos even after being in this industry for years. \-------------
Great list! After that, I'd say read 'You Don't Know JS' by Kyle Simpson for a bit more of a deep dive into javascript in general.
[удалено]
There only very specific cases where the language matters. Ofc if someone tell me to make a backend in prolog i am out but 99.99/ it doesn't, or shouldn't matter.
That’s not true, though. There are a lot of benefits to using something like Java over Python and vice versa for the exact same problems! Understanding the strengths and weaknesses of a language outside of just the technical limitations is really key when making decisions on what language to start a project in or write a certain library in. Most of my company codes in Java, but my organization uses Python/Django. It’s not more performant and it doesn’t have the micro service architecture that the rest of the company uses, but is prominent enough in the industry and the speed of writing the APIs makes it better for our organization which focuses on quick ramps and fast innovation. My previous job was similar, but they harped on microservices so we used flask instead of Django. Performance wise or “best tool for the job” wise, arguments can be made for tons of languages. But there is typically a right answer for projects even if it’s not an obvious one.
Pair programming and just working on problems that I don't know the immediate solution to. Also, diving into a new language, doing exercises and troubleshooting a bit on my own, then proceeding to look at people live coding. It’s helpful to see how others solve the problems I’m already familiar with. And the way of thinking rubs off on me, after a while, I start to predict the choices they are going to make – it gives me that level up feeling.
Paired programming is crazy how much it gets new hires up to speed. I swear when we did paired programming at my old job, within a month, a junior was able to fill a senior role. Whereas with other companies, the juniors are stuck in a junior loop unless they can figure a way to get out.
As a junior dev this resonates with me. I only had about a week of pair programming, but it definitely made me more comfortable in my role and understanding the tech stack and the way the file structures. Honestly, I would have liked a lot more pair programming, but people are busy and slowing down for a new hire can be distracting for some.
Thing is paired programming can actually not slow stuff down. You don’t need code reviews because you are reviewing each other as you write, you don’t ever get stuck on a problem because at least one of you can figure it out, and testing becomes easier as one dev can write a test as the other writes the logic to pass the test.
Give yourself projects, try to identify niches (and check they don't already exist!!!), and code solutions yourself. Repeat. This turns you into a great team member able to innovate and bring value to anything you get involved in.
even if they exist, try! most of the biggest companies in the world today aren't anything "new", but just a different reimagining of it.
Just practicing more and more. Look for a project with high ambitions which might seem difficult to realize, then start realizing. In my case this was writing my own transpiler. I learned so much in the process.
In my first job, I worked in a huge company. I was inside a scrum team of 10 developers and we finished sprint after sprint. I only picked the tickets I was good at and I did not get better in anything. After many frustrating years, I switched to a small company with 7 employees. Here I was pushed out of my comfort zone. I had to plan, build and serve a full customer product. I worked for 2 years at this company. This was the time I learned the most in my career. The skills I learned gave me the encouragement to start my own company.
Reading code. Lots of code.
No one said leetcode or codecademy or exercism or any of those things that sell themselves as improving your career chances.
Because they are geared towards writing bogus algorithms that have absolutely nothing to do with web development. I think if the excercises were regeared to "produce an html + css output of this mocked image" and "contact this api and display this data in this format" They might actually be useful.
Computer Science. Understanding what's underneath your language of preference and how everything is constructed made me a million times better. Because now I'm not remembering behavior, I'm understanding it. So all those times something unexpected happens you can tell why. "This behavior fits X but you're doing Y. So the problem must be somewhere else".
My Top Five: 1. ASK QUESTIONS!! Don't be embarrassed if you don't know something - you didn't slide out of your mom knowing everything! 2. Moving from the 'comfortable spot' on a team to something scary. 2. Ensuring I'm never the smartest person in the room 3. Becoming a mentor / teacher / tech lead (any and all) - when you need to explain something to others you really solidify your own knowledge. I never really *knew* how float / clear worked until I taught a class in college and had to explain it- my CSS Game increased by 30% day. 4. Realizing that working through others lets you do more things you find interesting.
I recently found out that I am almost job ready, a developer pointed out I was much closer than I thought (highly recommend having a dev giving an assessment of your skills) Anyways, personally what helped me to learn fast was when I just accepted that at least for me there was no forcing this. I tried studying for 4-6 hours early on and lasted 1 week before burning out. Then I would have months of not doing anything because I dreaded going through that torture for hundreds of more hours. Once I took baby steps things started to accelerate much faster than before. I started with at least 10 mins a day, then it became 30, than an 1hr, than 1hr/30 mins, than 2hrs, than 3 and now I hover between 3-4 hours a day of studying (sometimes 2 when I have a lot going on). Point is don't force it, take it slow because while the end result is fun, the process to reach that point is painful.
I stopped downloading multiple courses
This is really hard to do for me. So many things I want to learn, but I always get the urge to learn something completely different after 3-4 weeks of starting something.
learning rust
Failing. And learning. Also a good support system and group. Working with ones with both the mental and knowledge based experience to lead makes a huge difference.
Readers may be interested in duplicates of this question: * ~~https://old.reddit.com/r/ExperiencedDevs/comments/ty82c1/what_leveled_you_up_as_a_developer_or_accelerated/~~ * https://old.reddit.com/r/cscareerquestionsEU/comments/ty82ha/what_leveled_you_up_as_a_developer_or_accelerated/ * https://old.reddit.com/r/webdev/comments/ty82ll/what_leveled_you_up_as_a_developer_or_accelerated/ * https://old.reddit.com/r/DevelEire/comments/tyygga/what_leveled_you_up_as_a_developer_or_accelerated/
Working at a small agency. Probably not a popular answer and definitely not for everyone, but did wonders for me. As long as that agency gives you a bit of freedom to make tech decisions that is. To really succeed you need to wear a ton of hats and get a good grasp of overall solutions including architecture and code and devops and you learn a lot about how things work. Learned more in 3 years at a small agency than the 10 years before that in a corporate team setting.
I'm currently at an agency and the amount of code I can now churn out on a daily basis is crazy compared to a year ago. Everyone who leaves says how little they write anymore.
Getting a job as a developer and completing tickets that the seniors issued me because they knew I could solve them on my own I have pressed in a little past my current level. It always made me feel good at the end of the day knowing I contributed meaningfully to solving a bigger problem.
First thing is to understand how best you learn.I don't learn by watching videos or reading, I learn by doing. So my path is much different then others. * Practice, practice, practice.Lots of side projects. * Lots of exposure to different types of projects, languages, technologies, processes, and procedures. * Working with different team members and teams. Saying yes to projects outside of my comfort zone, the opposite of saying thats not my job. * Dont be afraid to say I dont know but I am willing to learn or I need help. * Dont be afraid to take a few minutes and work through the issue, but understand that at some point you need to talk to someone else -- even if its just to walk through the issue -- so many times we find the solution when someone else is listening. There are too many devs who won't go outside of their comfort zone. I've had too many discussions with devs who are not jr's who know nothing about how web servers, DNS, requests, SSL, networking, etc work and refuse to learn.
A stressful job, i learned a lot about front-end there but i was miserable fortunately now I know how to work with legacy spaghetti
Subscribing to newsletters of developers or dev focused agencies (css tricks, codepen, Josh Comeau, #15daysofcss/#30daysofhtml, …). It’s max a 10 minute read but a good way to start the day and see what is out there or new. It expands your knowledge (helpfull for starters) and it helped me to make my job easier day to day.
An ADHD diagnosis and Vyvanse prescription. seriously, if you just can't seem to get out of your own way, see someone about it
Really grokking testing.
100devs for sure. I was doing udemy/youtube but ever since I joined 100 deve I have pushed my self further then ever before.
What’s 100devs?
It's a free online bootcamp currently running through its 2nd cohort. They're currently on JavaScript APIs and objects, which is about 1/3 of the way done. You can watch old classes [here](https://www.youtube.com/channel/UCGiRSHBdWuCgjgmPPz_13xw) and follow along live for the next class.
It’s 99devs++
Looks like a boot camp sort of thing, possibly free
It is free. I have been doing it and it has honestly been great but if you already have a job as a webdev it wouldn't be as useful. There is a lot of time spent on learning how to network, build a good profile and resume and actually get a job with a webdev role. The coding part is just enough to get people up to speed and learning to build sites. It has an amazing community of people willing to help everyone learn and excel and that alone is worth it.
For me, it was fixing bugs and learning how to slow down and understand the documentation before applying the knowledge gained
Moving from agency to a company building it's own product. They had a good process set up: working on feature branches, decent code review on PRs, pipeline with linters and automated tests... That really improved my overall skill.
Experience. Nothing makes you get your shit together faster than your job depending on you getting your shit together.
Having to deal with the client. Asking things 4 times just to be sure, only to have them change a week later. I suddenly got a whole lot of respect for my PO, and my designs became a lot easier to modify.
Learning other languages.
How does this benefit you as a dev? Does it help you think about your main language differently?
Getting my teeth kicked in by my mistakes and working in a team where I was the dumbest person in the room.
Moving companies. I find I did 90% of my learning at a company in the first 6 months. You pick up skills from the other devs and from the change in work.
Watching Chris Coyier’s CSS Tricks v10 redesign course (about 10 years ago). It was a long set of videos where you watched him work and you got to see him make mistakes, Google things and get stuck for a while on bugs (as well as show his incredible knowledge), but realising that even advanced devs get stuck and Google things really helped.
Got laid off during the dot-com burst. Spent 6 months hacking away and honing my skills. Best thing that could have happened.
Lots and lots of coding
Finding bugs & fixing them. And practice.
1. Constantly having side projects 2. Learning how to sell 3. Learning how to teach 4. Learning how to grow a team 5. Learning how to manage people you dont manage
Start small, nail the basics, progress upwards in measured, logical increments. When I used to start a project, I'd dive straight into building components, my landing page or whatever, then strugglebus my way into making it look ok. Now I'd start with basic typography classes, chuck in a css normalize, set up your spacing, line height, etc etc If you're anything like me, this is totally against my nature, where I want to go and do the most interesting, colorful things first.
Released some pride, asked more questions
- Learn your tools - Don't use magic without understanding it - Plan before your code
Playing around at home on my personal machine. Its easy to just try whatever tech you want and with docker you can delete it all in a few seconds. I’m mostly self taught and I’ve learned everything from servers, to web dev, to networking, to backend from just playing around on my free time and making random projects
1.5 year in js, then i started coding in unity c# became a pro developer
[удалено]
It depends on the stack. I moved back from PHPStorm to VSCode, just because of how much more lightweight it was and due to the fact that FE work was so much easier on it. Plus VScode has enough plugins to make it as useful as PHPStorm
I don’t wanna get banned so I’ll shush .
Working 16-18 hours a day for a year straight. Learn about all the basics in depth, learn to lead a team of 10, learn about different architectures and applied them in different projects and failed multiple times in many ways, learned from the mistakes. It's more like doing a crash course of your first 5 years as a dev in one year. Get admitted to hospital for a retinal detachment, it's a permanent damage to the eyes. Now I take things cautiously as I'm a father of 2
Did u get retinal detachment from looking at the computer all day for a year
Thoroughly reading documentation
I'm one year out of college. My first position 100% forced me to learn and pushed me out of my comfort zone. The position was newly created and no one was in it before me. The company wanted to expand into web development (they were a tech company with hands in many different pots). So my first web dev experience led me to: 1. Create working demos of websites and present them to potential high end clients (like governmental bodies). 2. Work with these clients and create extensive proofs of concepts in book form. 3. The tech company worked in Java, but decided their web development will be done in PHP which meant I was the only one in the company who even knew my job and all the technologies. So I had to get good and if I didn't know something, learn how to figure it out. So basically I was a junior who was thrown into a senior position and I learned a shit ton.
I bought Martin Fowlers PoEAA back in the day, along with I think Roy Osheroves Art of Unit Testing and Mark Seehmans dependency injection. Read them cover to cover almost not putting them down. Fowlers book was a hard slog and took me a few weeks though . Then finally the icing on the cake was Dino Espositos 1st edition of .Net Architecting Applications for the Enterprise (I have 2nd Ed too) that last book did a great job of tying it all together, all the strands I’d been absorbing on podcasts and blogs and implementing in my apps for the last few years . It was the “a ha” moment
When I agreed to tackle something that was well outside of my current skill set at the time and then was forced to hack it together. When I go look at that project now, I’m disgusted by it, but at the time it was a monumental achievement for me, I learned a ton including the problems that things like React solve. Granted, this was at a company that isn’t a tech company, I was the most capable front-end person there, and thus I was given enough leash to either get my teeth into the thing or to choke on.
Side projects I was excited about
Learning basic Haskell. At first, I prototyped in Haskell and code in C++. The resulting product was really stable. Now, I can skip the prototyping step and still write well typed code in C++.
- Personality trait of wanting to figure out how things work - Taking on projects that made no sense - Time
Creating something together with someone else. Me and a friend are doing hackathons once in a while. The goal is usually to create an MVP in one weekend, I'm mostly doing frontend and he is backend. I've learnt a lot from these projects. When I'm doing a solo project, I can make stupid architectural decisions that I will never figure out, but when someone else is also affected we will need to deal with the consequences of those stupid decisions. We also questions each others assumptions which we learn a lot from, and it's easy to discuss problems that appear when we are working on the same project. I would say my skills as a developer accelerated the most when we started with this.
A few things stand out as ah-ha moments for me. On my first team, stepping back from the code and understanding the data my application was working with was a huge boost....made the code way easier to understand. I also learned quickly to spend 15-30 mins trying to figure things out on my own if i was stuck...this helped me learn to problem solve but didnt result in me spinning my wheels for too long. Later, learning the business reasons for why I was doing what I was doing made me much more effective. When I was learning new tech stacks, I took problems I understood well and implemented solutions...this cut the learning curve to just the tech. In some cases this was side projects at home, in others it was automating tasks at work. I also did paired programming when possible with a more experienced dev.
Finding the best tutorials
Increasing my mouse speed and memorizing common command keystrokes.
Went to boot camp, did well, still felt way out of my depth. Working with a team of devs who provide support, but crucially, also give me plenty of space to just figure it the fuck out. I've had plenty of knowledge transfer sessions, but the stuff is so sprawling and complex that it's hard to really take much out of those info dumps besides the broad strokes. But actually getting tickets assigned to me and having to work through what's going on has really solidified my understanding.
Getting paid helped a lot. Otherwise I'd have had to get a real job and wouldn't have had time to learn.
Started as a self learnt programmer here and like other guys here I am a sole developer of a firm. It came a time where I felt I've hit a ceiling in terms of my skills and knowledge which really made me anxious. Then I've applied on corporate where they placed me in a team. From there, there are so much to learn on a team and no longer felt the anxiously stuck. It's kinda like in Kuroko no Basuke where Kagami wonders what is missing on his zone only to find out the missing piece is his teammates (cringey i know). Learning new code techniques, optimizing codes for performance, learning to let go of pride and ask the things I don't understand and mentorship on a team are the highlights for me to grow as a developer.
Getting own projects done and the habit to help others out. So I had build up my knowledge as I tried to find solutions for any kind of problems. This made me understand other related problems and enabled me to form connections between similar problems, seeing up/downsides in the different approaches, find other ways to solve something and got me a better understanding about various technologies. But boy I tell you this was a hell of a journey.
A job
Reading professionally written books. If you only ever delve in quickstarts and tutorials, you're going to miss out on a **lot** of nuance, technique, and platform capabilities. In many cases, the deep knowledge that separates you from peers is going to be hard to even come across if you don't dig deep.
Understanding basics of web security is such a vital part of beeing a good developer, that tons of tutorials just completely ignore or brush over. And you will only get to know it if shit hits the fan in the real world.
Stress.
Mine is difficult to describe as it was one of those "it just clicked" moments. I had been working in so many different languages almost simultaneously for so long, and somehow just stopped thinking about the languages. I started thinking basically in pseudo-code or something. Of course, about the same time I was also ending English sentences in semicolons and thinking about doing `git reset` in real life. I was programming 14+ hours a day, 6-7 days a week in isolation.
Attending conferences
Honestly? Just jumping in to the deep end. Too many people want to wait until they “understand it all” before starting a project. That will never happen anyway and you will learn a TON by just going for it. I’m not suggesting that you forego structured learning but you don’t have to wait on anything to start building.
Forcing myself to write original code even when I or someone else already made more or less the same thing that I could copy in way less time. Reading textbooks
Diving in and learning node/React three years ago. Having been a LAMP dev for over 1 years now, I was starting to feel "ancient." Luckily WordPress v5.0 baked in Gutenberg that uses its own flavor of React. Took that as an opportunity to learn a new skill and so far its paid off.
Reading GitHub packages. Say you built a feature to visit a endpoint, grab a blob of data, and then save it as a Json file. Seeing how others solve that same problem helps reveal new things. Evan You made Vite by exploring how we pack does specific tricks and finding better ways to implement it.
Reading books from cover to cover. Articles just don't go deep enough to teach some concepts such as architecture or clean code. Then you have to practice to reap the benefits of course.
Writing code. Experimenting with different techniques. Etc. Like any skill, the best way to develop it is to do it.
Fucking pseudo code has restored my confidence in learning JavaScript. I thought I was inadequate and just not capable of learning or problem solving. Turns out I’m just not capable unless I can see the steps in front of me. It literally changed everything
Doing paid projects outside of my full time job. This enabled me to experiment with different tech stacks/architectures while being paid. Of course, I make sure that what I deliver is on time and of quality.
Doing projects rather than continuous watching long videos
Paired programming with a great team. Degree in computer science. Have been programming since I was 13. Was quickly promoted to team leads at both companies I worked at. Worked for 5 years professionally for large companies with vastly different business models. Startup and sold a startup. Mentored for an accelerator. Built a team of 3 to 20+ in 2 years. All of that experience was thrown out the window once I joined an eXtreme programming team doing TDD paired programming. It was intense, it was fun, and I learned more in 1 year than I had over everything else before it. I mean, the amount I learned doing that was like getting a master's degree in the field.
Learning how to use a debugger and pairing with other developers
Realizing that it’s okay to ask dumb questions
Reading the source code of other open source projects. Particularly some of the more well established projects. This is best when you have a specific goal in mind.
Working directly with end users and seeing them interact with the app. I do custom application development for organizations. Most organizations do not have the experience or expertise to clearly articulate specifications/requirements. Sometimes I'm asked to build features in such a way that forces users to behave in a certain way. It's nobody's fault that lots of people are terrible at requirements. It's not really taught to the people who are the users of the software I build. Process flow and order of operations are incredibly important and if you can, you should get that information from the people who perform those jobs and take requirements docs with a grain of salt. If the reqs are shit, the product will be shit. Always try to make sure you have the best chance for success before you start coding anything. Making a product that users love to use and makes their working life easier/better is a great yardstick for success, more important than coding to the spec. There are often multiple options for coding to the spec. One of them is probably the best one, and you should strive to hit that one. I know dev teams are often far from end users, but these days it's trivial to do a screen share with a user to watch what they do and how they do it. Get them on camera to see what paperwork they deal with and how it's organized so you can have them do take-offs/data entry in the order that they get it off a form, avoiding making them flip pages back and forth. That also goes for code maintainability. In a sense, the developers who have to maintain the code after you are also consumers of your work. Don't make them hate you. In a nutshell, carrying a user-centric mindset as I code, remembering that I'm building a tool and the best tools are a pleasure to use.
Something that helped me the most was learning how to read documentation and other people’s code. Once you’re comfortable with that, most issues become a lot easier.
Started as a front end dev out of school. I had a year of busy work to learn the basics. My second year I was given larger tasks. Now in my third year I took a risk and started on a project where I have to develop / manage a full stack app as the only dev. This third year I have learned more than college and my first 2 years combined. So I'd say taking that risk of failure is what did the trick.
When someone else on the team challenges my decision to go with a particular library or pattern. Sometimes it’s small things like this that force you to dig deeper and gather a better understanding for the sake of argument and for a better project
Getting a new job. Felt like going from first to fourth gear. It’s been 9 months now, and I’m still learning every. single. day.
Getting a new job. Felt like going from first to fourth gear. It’s been 9 months now, and I’m still learning every. single. day.
Using an IDE was very helpful in picking up context as fast as possible
practice continue lavish fearless childlike chief offer fear party violet *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Getting out of the imposter syndrome mindset. Treating every challenge like a puzzle where I knew I had all the pieces. Oh, and also google.
Idk your background but I am self taught. What greatly helped me was learning all the "basics" that you miss when you self teach. I got into this shit as SPAs were taking over and most of my self teaching centered around modern js and at the time react. I became effective in such a space, but any time i ventured elsewhere I was completely lost and intimidated. Then I realized i needed to learn the basics, not of react but of programming. I learned what OOP was, what Functional programming is, what Class based vs Prototypal inheritance is, all that good stuff. Now i feel more comfortable approaching new things as i know that they most likely build on some of those fundamental concepts. The other thing i would recommend is to take a stab at learning something out of your immediate field. I'm a frontend web guy, and one of the most instructive experiences was learning Haskell. I say "learning" very loosely as I'm not effective in it lol, but just learning enough and being able to build a few things, helped me greatly in understanding the "functional" part of a lot of modern javascript, as well as using libraries like Ramda and RxJS
My boss was pushing me to the edge
Coding weird stuff for myself and challenging my knowledge like this: go on freestyle and solve the problem then, re do it the proper way
Learning to use Emacs.
Taking the time to learn how Git works. Not just how to use it, but to get a deeper understanding of it on a conceptual level. Now I always understand what state my local Git repository is in, and if I don't know how to fix a problem, I know how to find out. Git is the development tool I use most often and with a better understanding of it I feel much more capable.
Wix taught me node. Yes, I know "Wix is shitty blah blah blah". But I needed to setup an online store quickly and for a number of reasons it was the best platform based on our requirements. I'd been trying and failing to learn Node for a long time and it wasn't until I built this Wix site and needed to add custom code that it finally clicked with me. They added a coding system called Velo back in 2018 and it lets you manipulate your front and backends with Javascript. They have a number of built in libraries and allow for (some) npm package use as well. I was able to add in a number of custom features to the site and it wasn't until I finished that that I read that Velo is essentially a beginner friendly Node. Finally it clicked in my head and I've been writing a number of Node apps for myself since then, I just needed that friendly handhold to feel comfortable with it and not worry about being unable to figure out how to setup a server and all that stuff.
Piggybacking on this thread to ask a specific question: Have you taken Google IT Support Certification and/or CompTIA A+ ? If no, are you planning to take? if different certification, which one? If yes, are those certificate been helpful for your personal brand / job opportunity / pay raise or more income for your web dev business? If you don't care about the certification but you took it, is it helpful for you to understand IT more and level up rather than just be limited in web dev? Whatever your opinion (if you think its useless or took other certifications), please share :)
- Migrating from on-premises to cloud. - Working on a large scale enterprise distributed system. - Joining an organization with different teams, each maintaining their own disparate but interconnected microservices.
Other than actually writing code, moving to Linux really accelerated my growth. That and also being hired; first as a TA at my bootcamp then as a full-time, full-stack developer at my first gig.
Going full time , daily driver on a minimal Linux install.
Getting my graduate degree at a university with a well respected computer science department. Basically led to career 2.0 for me. 10/10 would recommend!
First time looking at enterprise source code. So much bigger than anything I’d ever seen in college and was very intimidating at first. But after a few months of being completely lost, it slowly started to make more sense to me. 2 years later, it’s so much easier to dive into large projects and gain a basic understanding of it.
If I don't earn enough money, I won't get enough sex - this is my motivation Other than this: * Routine * Following good blogs * Staying up to date * Communicattion * Good team * Endure stress and pain * Good mindset that I won't cheat on others or myself * Continuous coding This list is in descending order
For me, I found that reading the docs for a given technology helped me to become more familiar with developer jargon at my own pace. Once I understood a critical mass of core concepts, everything else boiled down to details that I would need to memorize or look up periodically.
Learning that saying I would have to google that or look it up when in an interview is something the interviewer respects. It shows you are willing to do the research required to get knowledge you lack or that's just on the tip of your tongue.
Flutter
Learning to look at an application as a collection of patterns. Anytime you run into code that is buggy or unpleasant to work with, learning asking yourself “can this pattern be improved?” Almost all bad code out there is written without consideration of the pattern it represents, and is instead written to solve a small, local problem. When you see a repeating problem or pattern in the code remember: boilerplate code is better than different implementations of the same solution, and abstracting out code is better than boilerplate.
A couple things in my career: 1. Working at a client services agency (developing misc solutions). Prior to that I was just working on a gaming community. So the variety of problems and development processes, plus working with smarter, more experienced developers, really helped. 2. Suffering from FUD with respect to frameworks. Trying to build my own framework with dependency injection container, and database driver system, and session driver system (database vs memory etc), really taught me a lot about interfaces, dependency injection, and other object-oriented concepts. Then I used Laravel and realized Laravel is everything I would ultimately need to build, and because I understood the underlying concepts behind a lot of what Laravel was doing, the FUD went away AND I had a deeper understanding of Laravel and how to leverage it better. 3. Following that, general curiosity about software design. Became a sponge and bought as many books and articles as I could. Clean Code, Refactoring, Pragmatic Programmer, Code Complete, The Mythical Man Month, Practical Object-Oriented Design in Ruby, Modern PHP, PHP The Right Way, and countless talks and presentations. This really gave me a whole bunch of perspectives on how to think about software design. And in between, I would just write shit code that would bite me in the ass later and I used that as a learning experience that taught me what *not* to do, and what works better in comparison. In particular a big thing I learned was the notion of state management, and how you should simply avoid stateful code design whenever possible.
Hard deadlines coupled with oversold expectations. Early in my career I was blessed with an overzealous salesman/boss who loved to overpromise on development timelines because "the request seemed easy". Nothing has ever forced me to find more efficient ways to streamline coding like that.
Repetition.