Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "wk377"
-
Advice to new coders? I got multiple, unrelated to each other.
1. Start with the FUCKING BASICS !! Invest some time with fundamentals, don't just directly jump on frameworks like React or Angular.
2. You and everyone else are always going to blame your technical skills if you're unable to land a job. But you have to realize that is not always the case. Your attitude and energy towards the interviewer plays a vital role too.
3. You're gonna have to take a hit to your salary expectations starting out. It's just the way this industry works.
4. Think of yourselves as a freelancer working for companies. Those who call themselves Employees get stagnant and dependent on their company pretty fast.
5. Your objective is either to learn or earn. If there is both, amazing job. If there is either it's good enough. If there is none, time to jump ship !!
6. HR is there to protect the company from you not the other way around. Be better at spotting crocodile tears.
7. Try to find a WFH job over a WFO job. If you have an urgency, then either works but keep applying to WFH jobs. It's the best thing.
8. Focus on what you're building instead of what you're building it with. Devs have a tendency to fight over what tech stack they should use instead of focussing on the larger picture.
9. You're gonna get overwhelmed at some point when you're gonna get terms thrown at you like XML, JSON, API, Figma, Git, SOAP, REST. Don't worry though you'll get there.
10. You should know how to google your solutions, like really. This is like 60% of the job.19 -
You will have a first phase when you will do everything on your own.
Then you will have a second phase when you will totally rely on external libraries found on the internet.
Then you will have a phase when you will use libraries only for the stuff you don’t want to bother because, never reinvent the wheel but do not get too much tech debt.
Then the hyper simplification phase when you will refuse modern solutions for good old robust stuff as they used to do back then
Then I don’t know… but I am getting interested in agriculture
Anyway try always to learn new stuff and don’t be afraid of change as it is normal. And learn other skills not related to code, those will keep you alive1 -
Ask yourself a couple of simple questions:
Do you like to code?
Do you like to learn new things and improve?
Do you like to solve problems and spend hours on a single detail until it finally works?
If your answers contain a "no", then development is probably not for you. You will hate it and you will suck at it. And you will make lifes of devs who actually love it miserable. So do something else.6 -
> Advice to new coders
Don't worry over picking language A or B.
Just pick A, use it for a month, then move on to B.
In a normal 3 year college degree you'll try multiple languages, some of which you'll never use again, and they'll each teach you something.
I had classes in Java, C, C++, C#, Prolog, Assembler, F#, JS.
Never used F# again and no one uses Prolog. But they were great for learning recursion and logic.
It's not like you take "a step down a bad path" if you pick a language you're never gonna use again.
You'll also learn new stuff on the job. We have one team that uses Go and one that uses Rust. None of the devs ever studied those languages. They were mostly former Java devs who leaned on the job.2 -
You may always feel behind. You aren’t alone. Find something you enjoy within coding. Don’t be a hero and pick all the tickets. Pick what you can achieve. Pick a long-term ticket that you can call yours and own it and learn from it.
BE KIND YO YOURSELF.2 -
1) Never be afraid to ask questions.
There are so many instances of situations where assumptions have been made that shouldn’t have been made, resulting in an oversight that could have been rectified earlier in a process and wasn’t.
Just because no one’s asking a question doesn’t mean you’re the only person who has it.
That being said, it’s really important to figure out how to ask questions. Provide enough context so that the audience for your question understands what you’re really asking. If you’re trying to troubleshoot a problem, list out the steps you’ve already tested and what those outcomes were.
2) When you’ve learned something, try to write about it. Try to break it down as though you were explaining it to a child. It’s through breaking down a concept into its most simple terms that you really know that you understand it.
3) Don’t feel like you have to code *all of the time*. Just because this is what you’re doing for a living doesn’t mean that you have to make it your life. Burnout is real, and it happens a lot faster if it’s all you do.
4) Find hobbies outside of tech!
5) Network. There are a number of great communities. I volunteer for and am a member of Virtual Coffee, and can vouch for that community being particularly friendly and approachable.
6) Don’t let a company pay you less than industry standard and convince you that they’re doing you the favor of employing you.
7) Negotiate salary. Always.
8) If you’re a career transitioner, don’t be afraid to talk about your previous work and how it gave you experience that you can use in programming. There’s a whole lot of jobs that require time management, multi-tasking, critical thinking, etc. Those skills are relevant no matter where you got them.
9) If it takes a while for you to get a gig, it’s not necessarily a reflection on you or your abilities.
10) Despite what some people would say, coding’s not for everyone. Don’t feel like you have to continue down a road just because you started walking down it. Life’s not a straight path. -
Pretty sure someone else said it before but: chose something else.
The market is over saturated with developers. There are plenty of other spaces in which you can work with computers and code.
Think: system administration, cyber sec (which also pays higher in a lot of places compared to development since resource security is a priority), networking etc.22 -
Don’t be cynical and prideful. Respect people older than you in the profession, even if in your judgment they are “dinosaurs”. Even if they’re not as well-versed in what you consider “The New Shiny Thing”, they’ve seen some shit and can teach you a thing or two.6
-
Thought hard for dem advice and dem advice is about softskills / collaboration:
- do dem ticket administration right
- prepare dem standups
- use dem dem where needed8 -
Everything that works on your machine, will most likely fail at scale.
Ensure that you have the right toolset. Learn more than just scripting.
Learn databases1 -
-Learn git early on
-Learn the basics of the web stuff even if you only want to be a backend dev
-Learn SQL. 99.9% you'll need it regardless of where exactly you land in this industry
-Build, build, build, build. Don't get stuck in tut hell9 -
Do the hard stuff first. Then everything else looks easy. Make a mess of the code, then fix it and make it efficient.4
-
Try to be a know-it-all. But don't try to *show* that you are a know-it-all.
Try to be a do-it-all (at your own risk). And show that you can be a do-it-all.
Be very very very careful in all environments except dev env. Actually try weird stuff in the dev env!
Asking for help is an art on timing (how much have you tried on your own before asking your seniors) and communication. (how clearly you can convey what you've tried) -
Code as often as you can. Don't burn yourself out, you don't have to strive for a daily masterpiece, but do something.
You're just starting and these new skills need constant work I you don't want to lose them immediately, so if your company tries to put you on something else that's not your job, don't be afraid to say no. If you start working IT for them "just to help out, just for now", you'll undo all your hard work and have to start again from scratch down the line.2 -
Compromise.
I think that sums up development pretty much.
Take for example coding patterns: Most of them *could* be applied on a global scale (all products)… But that doesn't mean you *should* apply them. :-)
Find a matching **compromise** that makes specific sense for the product you develop.
Small example: SOLID / DRY are good practices. But breaking these principles by for example introducing redundant code could be a very wise design decision - an example would be if you know full ahead that the redundancy is needed for further changes ahead. Going full DRY only to add the redundancy later is time spent better elsewhere.
The principle of compromise applies to other things, too.
Take for example architecture design.
Instead of trying to enforce your whole vision of a product, focus on key areas that you really think must be done.
Don't waste your breath on small stuff - cause then you probably lack the strength for focusing on the important things.
Compromise - choose what is *truly* important and make sure that gets integrated vs trying to "get your will done".
Small example: It doesn't really matter if a function is called myDingDong or myDingDongWithBells - one is longer, other shorter. Refactoring tools make renaming a function an easy task. What matters is what this function does and that it does this efficiently and precise. Instead of discussing the *name* of the function, focus on what the function *does*.
If you've read so far and think this example is dumb: Nope... I've seen PR reports where people struggled for hours with lil shit while the elephant in the room like an N+1 problem / database query or other fundamental things completely drowned in the small shit discussion noise.
We had code design, we had architecture... Same goes for people, debugging, and everything else.
Just because you don't like what weird person A does, doesn't mean it's shit.
Compromise. You don't have to like them. Just tolerate them. Listen. Then try to process their feedback unbiased. Simple as that. Don't make discussions personal - and don't isolate yourself by just working with specific persons. Cause living in such a bubble means you miss out a lot of knowledge and insight… or in short: You suck because of your own choices. :-)
Debugging... Again compromise: instead of wasting hours on debugging a problem, ASK for help. A simple: Has anyone done debugging this before or has some input for how to debug this problem efficiently?... Can sometimes work wonders. Don't start debugging without looking into alternative solutions like telemetry, metrics, known problems etc.
It could be a viable, better long term solution to add metrics to a product than to debug for hours ... Compromise. Find a fitting approach to analyze a problem instead of just starting a brute force approach.
....
Et cetera et cetera. -
Try to learn stuff instead of copying stuff together that may work but you don't know why or how. If you don't care about the why and how, look for another career/hobby.1
-
My advice would be to have fun with coding and make things that you like. Consider all other job fields. Only work in programming if it makes you fulfilled and gives you good memories looking back. If you do work as a dev, be passionate about making the code and projects beautiful and high quality. Search for mentorship from developers you admire.
-
If you don’t like debugging, you are not going to make it. It’s going to feel very difficult to move ahead.
You really really have to love finding that sneaky little bug digging for hours at end.
Other than that, it’s all practice and common sense for me.2