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
-
To all new devs:
- Your language of choice is fine.
- There is no superior way to indent, yours is fine.
- Your IDE is fine.
- Your OS is fine.
Unless you work in my team, of course.18 -
What advice would I give a new dev?
"Learn COBOL"
No one specified that it had to be 'good advice'7 -
0. Plan before you code. Document everything. You won't remember either your idea or those clever implementations next week (or next month, or next year...).
1. Don't hack your way through, unless that's what you intend to do. Name your variables, functions etc. neatly: autocomplete exists!
Protip: Sometimes you want to check a quick language feature or a piece of code from one of your modules. Resist the urge to quickly hack in the test into your actual project. Maintain a separate file where you can quickly type in and check what you're looking for without hacking on your project (For example, in Python, you can open a new terminal or IDLE window for those quick tests).
2. Keep a quiet environment where you can focus. Recommend listening to something while coding (my latest fad is on asoftmurmur.com). Don't let anything distract you and throw your contextual awareness out of whack.
3. Rubber ducks work. Really. Talking out a complex piece of logic, or that regex or SQL query aids your mind greatly in grasping the concept and clearing the idea. Bounce off code and ideas with a friend or colleague to catch errors and oversights faster. Read more here: https://en.wikipedia.org/wiki/...
4. Since everyone else is saying this (and because it merits saying), USE VERSION CONTROL. Singular most important thing to software development aside from planning and documenting.
5. Remember to flout all of the above once in a while and just make a mess of a project where you have fun throwing everything around all over the place. You'll make mistakes that you never thought were possible by someone of your caliber :) That's how you learn.
Have fun, keep learning!3 -
Don't get too comfortable.
If your workplace isn't much of a learning environment, it's either time to learn on your own time or leave that workplace.
Don't be arrogant with those who are less tech savy. If your boss/cowoker doesn't understand, at least give them them a chance ☺.
Be kind to new developers who make mistakes; you were in their shoes once.
Realize there's more to life than just designing and implementing software. Don't let other areas of your life suffer just because you're a godly developer.3 -
Do not disturb someone especially if they are in the zone.
Hint : earphones on, a ton of error logs on screen.4 -
When typing analytics.google.com into a browser always type more than 4 characters before hitting enter.9
-
Things I wish I could tell my 18 year old self.
1) Accept you will make mistakes.
2) Truly learn the language you are using.
3) Write idiomatic code for the language you are using.
4) Be upfront about not knowing something.
5) Don't let not knowing something stop you from learning it.
6) None of us knew X until we learned it.
7) Understand your strengths and weaknesses as a developer, play to them.
8) Be willing to try new things.
9) X language isn't ALWAYS the best choice, X paradigm isn't ALWAYS the best choice. Choose wisely.
10) You won't know everything, but you might know more than others.
11) Your ideas and ego don't matter more than ensuring the product works.
12) "Perfection is the enemy of the good [enough]" - Voltaire
13) "Perfection is not achieved when there's nothing more to add, but when there's nothing more to remove." - Einstein.
14) Conflicts happen, deal with it.
15) Develop a toolset and really learn them.
16) Try new tools, they may prove better than what you were using.
17) Don't manage your own memory unless you absolutely have to, you are probably not smarter than the collective intelligence of the team that built the various garbage collection methods.
18) People can be dicks, especially online.
19) If you are new and people are being dicks to you, did you skip past the irc message about etiquette? If you did, you're the dick in this situation.
20) It can be tough, but it is fun, so have fun!6 -
If you are copy pasting code from somewhere else, spend some time and effort to understand what that piece of code is actually doing, and how much of your requirement does it satisfy.1
-
Learn git. For real. Not just git pull and git push. Setup git with a mergetool and do the gitimmersion tutorial. Be the gitmaster!6
-
Don't BS your managers or peers about your understanding of a topic.
It is okay to not know something. It is not okay to pretend that you do.3 -
Advice that I give to interns/grads:
In uni/college, you're taught *how* to code something to achieve a goal, and 99% of the time the code will work and do the job in a lab.
But when building things for a real production environment, you learn the 100 ways how *not* to code, from seeing things break left right and centre - basically everything and anything can break your code, whether it is users, the OS, other people's code, legacy code, lag, concurrency, the alignment of the moon to your server...5 -
Stop reading and JUST start writing code.
I've been stuck in coding limbo because I kept looking for the right answer.
And I've learnt over time that the right answer will come to you only when you know what exactly you're looking for.
So start coding.10 -
There are no stupid questions.
Just look at stack overflow... Plenty of stupid questions with answers1 -
Always put yourself out of your comfort zone. Always. It's the main source of both anxiety and personal growth. Don't think that you're a fraud because you can't understand the new stuff right away, how else would you learn? Looking back you should always be impressed on how much you've covered, but still have anxiety of what's to come.4
-
Name your stuff in English. Variables, functions, files. Everything.
You make the code completely unmaintainable for everybody that doesn't happen to speak your language otherwise.
I cringe every time I see someone in our company use German in his code. Just don't.9 -
Don't work late/during the weekend because someone else committed to an impossible deadline. Trust me. It's not worth it.3
-
- Take walks at regular intervals.
- Get enough sleep (I know it's hard)
- Don't stress
- Enjoy the journey -
Master vanilla JavaScript.
Once you do, you'll be able to quickly learn how to use all the frameworks.
And no, jQuery is not vanilla JavaScript.23 -
Never put more than 1 sentence in an email. People never fucking read more than the first line. Then they fire back an email with questions you already answered. Arghhh bastards.1
-
Don't put a hack and leave comments like "// HACK: Remove this later". It's gonna stay there forever. Trust me. Do clean codes from the start!2
-
Comment the "why", not the "what". If your code needs comments to explain what it does, rewrite the code (use good, descriptive identifiers).3
-
If you are tall and experience back problems like me, give one of those balls that you sit on a try. It costs 15 euros and it solved everything for me. If it doesnt... well... throw it of your balcony and let me know how high it bounced4
-
"Senior Engineer/Dev/etc." is just the title for the guy who's learned from making the most mistakes.2
-
Don't be lazy when naming things. You yourself will be lost in all the a, b, c, ds, let alone your code reviewers.4
-
This is more on work and life balance.
1. Don't do hard work, but do 'Smart work', else you will end up burn yourself 100%.
2. Don't think your manager is your guardian angel, even though it seems like sometimes. He has his own goals to achieve.
3. Spend considerable time daily in and out of office/work, for your own development/improvement.
4. Learn new languages and technologies.
5. Stop making things perfect, 'good' is enough.
and it goes on ............3 -
Don't be afraid to make mistakes, they're the key to learning code/anything.
A wise man once said:
"The only difference between a master and student, is that the master has failed more times than the student has even attempted"2 -
Week 26 advice - you all probably know this but good to refresh!
Eat healthily
Sleep well
Document clearly
Annotate your code
Use version control properly
Keep yourself in check with project management tools
Your peers are your friends... And competition.
As much as your boss is an idiot respect them and your life will be easier.
With great power comes great responsibility; don't touch that keyboard until you think through what you are doing chances are your first idea is not the best.
Don't write quick fixes and say you will go back to clean it up later on when you have time. That time will never come.3 -
To paraphrase Jeff Atwood: everything you write sucks. The goal of programming is not to write great code, but to writes code that sucks less each time you write code.
-
“Never,never, never, NEVER eat raw userinput“
Referring to stuff like “insert into foo (bar) values ($_POST[username])“2 -
Always answer these 2 questions in your commit message: (1) what will happen if this commit applied? (2) why this change is being made?2
-
If you're an aspiring web dev, get comfortable using the command line.
Amazing how many new starters can't restart a service or tail an error log.
I'm not saying it to be a dick, it's just 101 stuff that'll save you loads of time.1 -
Don't attempt to reach the Balmer peak at the office without first practising at home.
It will take many attempts to know how much you need to drink to achieve it. It's a fine, fine line. 🙃3 -
Once a day, take some time to read your colleagues' commits.
You will see how they work, you will learn how they solve problems, you will understand their flow and you will know more and more parts of the code base.1 -
Writing cool code might be your passion but shipping it is your job. Sometimes they are not the same thing unfortunately... and its ok!3
-
Don't be afraid to question senior devs as you go through your career. You'll learn a lot yourself, and any senior worth their salt will be open to the dialog. You'll learn a lot about the topic and potentially about the people you work with. Never stop learning and stay relevant with technology.1
-
If you've spent time learning how to code and you're daydreaming about having a dev job but don't have one because you're too nervous to apply, just do it. The worst thing that can happen is that you'll get the job (and be stuck ranting like us).4
-
One thing I learnt after over two years of working as a programmer is that sometimes making your code DRY is less important than making your code readable, ESPECIALLY if you're working on a shared codebase. All those abstractions and metaprogramming may look good in your eyes, but might cause your teammates their coding time because they need to parse your mini-framework. So code wisely and choose the best approach that works FOR YOUR TEAM.7
-
Look to your left, then look to your right...
All of those devs started out exactly as you are doing now!7 -
Never accept a deadline you think you can can make if you work really hard. Just to please a client.
-
"C'est en forgeant qu'on devient forgeron", a French proverb.
(Means : it's by smithing that you become a blacksmith) -
Tests!
Before you write a piece of code, write tests which will check that the code does what you expect. This helps you in two ways:
1. It forces you to think about and understand the purpose and aim of the code you're about to write before you start hacking away at it.
2. You know when you're finished, because the tests will pass.1 -
There will be always someone who is a better programmer than you so don't stop improving on yourself.1
-
1. If you dont know, say: Let me check that and get back to you.
2. ALWAYS use legit test-data and test-images.
3. Never argue ten minutes about something you can fix in ten minutes.
4. Fuck blame or glory. Just refactor and commit and feel proud about youself.1 -
Get yourself a proper set of peripherals (mouse, keyboard and chair), you will be using them quite a lot, so don't skimp out, it's you livelihood, so take care of it 🙂1
-
VoIP meeting today lasted 7 minutes.
I have kept the board down to ~5 ticket average for the last 3 months.
Co-worker(jokingly): I guess we don't need you anymore.
CEO: Quite the contrary. @chenb0x may need a promotion.
Me: *smirks*
This is why I like working for this company. Love the culture....no matter how much I may bitch about the clients.
'How did I get here?' a young dev may ask.
1. Delegate where proper
2. Script whatever can be scripted
3. When the board is low in tickets, it becomes a recursive responsibility to keep it low.
Back story
-----------------
When I was hired, the VoIP board was sitting at a ~30-40 ticket average.1 -
Tools don't matter. Use what is comfortable and don't listen to all the brand, OS, editor and tabs/spaces crap. They all do the job and you will find the right ones once you really understand what you are doing. "Tools can be just a way to procrastinate". If you become tool agnostic you can do the job no matter the environment.1
-
Dear new devs/me five years ago:
Practice the 30 second rule-- Whatever brilliant thing that your about to say, just think on it for minimum of 30 seconds. Is it still a brilliant idea? Then share. Else trash it 😉 -
If you can, attend programming contests, code retreats, and meetups, you'll learn a lot from that, experiences like have a fun talk with mate devs about this awesome environment while drinking some beers or eating some pizza is fantastic1
-
1)Don't overestimate your abilities. H1Z1 killer is probably too complicated project for starters.
2)Choose proper tools. Yes Notepad++ is not the best free code editor.1 -
Some advice:
- Be careful with the snack;
- Be moderated with your daily dose of caffeine
- And please, please comment your code even you will not know what were you thinking about when you wrote that 500 line method4 -
Stay curious and open-minded. If you hear something new take some 5-10 min and Google it. You will surprise much people even if you know just basics.
And if you're a fast learner, be aware, some people will be intimidated and try to oust you. But stay positive! -
It's not always your fault, sometimes your code will be perfectly fine and shit still won't work because someone else fucked up. Be careful which libraries you choose to work with.
-
Don't focus too much on learning one specific language. After some coding getting to know a new one is going to be no problem. Focus more on paradigms and maintainable code.
Oh, and don't forget, comments are sometimes way more useful than the actual code.1 -
Learn VIM. Unless you're doing Java or some other compiled static typed language. In that case: learn JavaScript and then learn VIM. 😎4
-
Read code, exceptions, comments carefully. Double think before asking. But never hasitate to ask if you are stuck.
-
Use a search engine!* I've known too many beginner developers that refuse to consult the web.
*I should add, make sure you understand what you find. Don't just copy a solution and not learn from it.2 -
Less stress.. No panic.. And yea.. Beer. Drink beer if you're really stressed... Helps me out everytime..
By the way I am drinking beer as I write this..
10 -
Never bother a senior enginer during his first hour of work. It is really annoying to just sit down and have someone doing 1500 questions. Hope you understand.
-
Even if you are solo, use version control and commit often. When you are working on something completely new, git reset --hard can really get you out of a bind.1
-
Never had the situation to give advice to a new dev. But I have an idea anyways: Give that dev a problem, which is above beginner level and watch the dev. If the dev rage quits and doesn't want to try again, then the new dev will not be happy with the job. But if the dev achieves to collect all knowledge to handle the problem, even if the solution is not the most elegant way, then the dev will have fun with the profession.2
-
Keep it simple, but at the same time try to build it so that any known or unknown future change can be easily implemented. Do not block your future.1
-
Documentation is your friend. I learned off of just documentation and experimentation and I feel I got a broader understanding of the language more than any tutorial could.1
-
If you are in a team, take advantage of their expertise. Code review with them can also save some headaches later down the road.
-
Don't know if I am experienced enough to give any advices but still:
1. Whenever doing freelance work, always take some advance payments, even its for your friends.
2. Use git even if you think it doesn't apply to you. I started really late.
3. Contribute to open source. You grow when the community grows.
4. Be humble even if you are the best there is!
5. Whenever you feel you are tired of this shit, remember why you started. Don't give up!
Most importantly, take time for yourself, family and friends. It won't be lines of code that you remember on your death bed!1 -
Always respect de YAGNI principle (You Aren't Gonna Need It). Maybe the hardest thing to follow, as beginner and after.
-
Never forget how it feels to be new and overwhelmed. For every question that you ask, remember that you should eventually pay that back by answering one for someone newer than you.
I think a lot of times, once developers get enough experience, it's all too easy to judge or make fun of those who are new for something they don't know. Remember that you were there once and lend a non-judgmental helping hand!3 -
Using the console to print out variables is a perfectly valid method of debugging for new developers: often, it can help you resolve the problem faster than using a debugger.2
-
Mainly for freelancers: Don't be afraid to take on projects you know nothing about. You can learn whilst doing the job, plus you're getting paid for it.
-
Be prepared to get it wrong, accept it and learn from it. Also if another dev corrects something you've done, don't take it personally. You can always learn from others.1
-
"My code" only exists when you work alone on your precious project. Do not carry over that mindset when you work with a team or you will just ignite another endless holy war1
-
- Code reviews are good for you
- learn and understand your tools
- ask and listen
- if someone writes code for you, delete it and build it again yourself -
Don't be afraid to make mistakes. Making mistakes is the only way to learn from them and grow. F*ck sh*t up and build it back up again but better. Fall seven times stand up 8!
-
Know your tools. Take some time to explore them. Knowing shortcuts, the capabilities of your IDE (and plug-ins), libraries and many more will look you like a wizard to others and can save you many efforts.1
-
If you start coding in Python3, don't use both tabs and spaces. Just decide for one. It'll save you a good amount of time on bigger projects 😉2
-
Wk26:
The moment you feel you've stopped learning find a new challenge. If changing jobs is scary pick up a side project, but if you're not enjoying or learning from your job, it might be time to move on.2 -
Fundamentals. Fundamentals. Fundamentals.
Seriously, though, don't cut corners. It'll bite you in the arse eventually.3 -
If you can't find the solution to a problem using Google, just try as long as you can. Think of all possibilities when a problem occurs. (Maybe even take advice from a person you don't like...)
-
Join a team that understands technical debt and actively squashes it...
Yes I am having a bad day, or should I say month, because I have to work to pay down other people's debt... -
There was a rant earlier of someone working a 9 to 5 job now which i can't seem to find, wanted to answer in regards to wk26
They were complaining about it being a boring job with boring processes and not learning anything new..
you can't say that you haven't learned something new, i bet you haven't learned a new language or technology but there are plenty of other skills to be picked up from a company that have worked for this all their lives..
I mean, these kind of companies have either seen it all already and had tons of bad experiences they are trying to avoid, or then never experienced any of them but are still trying to avoid them.
I once worked for a Japanese company in Europe. All decisions (big or small) were taken by answering with the phrase : If it isn't broken, don't fix it. As a result they had an excel with over 64k complaints in them (1 row per complaint) and their website was running on 19 Sun servers, load balanced, using php 4.2 because the technology was just too old.
Point being, plenty of things to learn, getting new experiences, even if they are bad, at least now you know, how not to do things in a certain way, but all in all, working at different places, even bad ones, gives you perspective..
And perspective is important.
Perspective is experience.
It's the bit that glues the knowledge together.
Go out and explore, don't be afraid, everyone needs bad experiences, even if it was only so we can identify the good ones. -
Just because someone has been a dev for longer than you doesn't mean they're better. In fact they're probably worse and you've seen monkeys write better code than them
-
Start with the simple things first then progress gradually.
Though I highly suggest learning unit testing as soon as possible. -
Learn to debug, breakpoints are your friends. Never ask someone help without trying yourself to debug your code.
Debug an existing code is, I think, as important than being able to write your own code.3 -
Never, ever, ever stop learning. And I don't mean sitting in a classroom overpaying for outdated information. Read blogs, news sites, community driven content. Find that thing that only a handful of people are talking about and learn it. Then do that again, and again. The second you stop learning, you'll be left behind. Does that mean you'll be unemployed, or find it impossible to do find work, no, not immediately. But if you stand still looking enough to gather some dust, you'll soon be part of the dust.
-
The only difference between a beginner dev and a veteran dev is that the beginner is afraid to touch what he doesn't know, while the veteran embraces it.
Accept that you don't know all and will never know everything. Even so, learn something new everyday. Fight your ego when it tries to make you keep only what you know and reject everything else. Fight that bastard.
The world needs less "I know", and more "I wanna know". And remember, devs should be in the "I wanna know" team.
sudo rm - rf ego
sudo apt-get knowledge-upgrade -
For the new/aspiring developers:
1. If you are still looking to learn more, but you don't know where to go, start brainstorming. Make a list of projects you could make and sort them by difficulty. Put the ones you could do now at the top of the list, and the ones you aren't sure how to do yet, at the bottom of the list. As you go through them, if you want to do something but aren't sure how, just hop onto an irc chat and everyone will be glad to help. As you go through the projects, your logic and program design skills should improve, as well as your knowledge of programming.
2. Put comments in your code. Seriously. If you are working on a project and suddenly stop working on it for a week or more, you will go back to look at that code and be extremely confused. If you are making something open source, its even more important. If people can understand the code, they are more likely to contribute to it.
3. Try not to focus on code for too long. The longer you work, the more tired your brain gets. Eventually you get tired and make really stupid decisions in your code.
4. Don't code while tired (look at #3)
5. If you are writing code as an assignment, make sure to rename all variables to proper names before submitting it. The instructor will likely not be pleased to see variable names with the f-bomb in them. -
Advice: always be thankful when you are the idiot because it is easier to change being stupid yourself than changing the other parties stupidity. Example: you can fix wrongly using a 3rd party SDK, but you can most likely not fix internal bugs in the SDK.
-
When you're new at a startup, never do overtime before you're regularized.
Enjoy going home early after work while it lasts. ;) -
You might think that getting your work done super fast is a good idea but it's really not. It takes QA awhile to test your tickets and give feedback. If you clear your sprint board, PMs will add more assignments... Then on top of that extra work, QA will give you feedback from your previous work. You now will be super stressed to get all of this done by the end of the sprint.
It is best to take your time and get it right the first time... I've also learned to make a buffer... which is tickets in my queue I've already completed but did not say I've competed yet. This way I can take extra time on tickets that need TLC and the PM team won't surprise you with backlog tickets. -
Advice to new devs: always check function return values. Crash as close to the reason as possible. Make your functions return errors whenever appropriate and check these as well, crashing gracefully.1
-
Always comment your code.
Write comments that explain the reason for this piece of code existing, and why it's written the way it is.
Don't write comments that explain what your code does (unless it's a comment which is going to be parsed as documentation for an API). If your code needs comments to explain what it's doing, you need to write clearer code. -
If you have the feeling you're facing a wall, that you won't be able to go further, don't give up! We all face walls at some points, they are common encounters in a dev life. Just don't give up!
-
When you think you suck something it's NOT your fault - learn how it's done in a different language or framework, then come back to it.
When you think you mastered something, it IS your fault - learn how it's done in a different language or framework, then come back to it. -
Do your research and be as detailed as possible when writing questions for StackOverflow. Often you will find your answer while trying to research or test your problem.
-
Newbies advice:
Never reject a task you don't know how to do just because you feel you wont be able to do it.2 -
Find what resets you mentally and use it to your advantage. For me it's either a shower or a long walk (with music). Both help me relax and gather my thoughts so I can start fresh.
-
Freelancing isnt for everyone, you have to be self driven, know your worth, know your skill level, know how long it takes you to write, and either have a few months of cash to setup your connections or live with somebody while you do
-
About the ongoing battle of tabs vs spaces, there is an option in most text editors to convert tabs to spaces ( if you press tab it insert a certain number of spaces ). Use that and you will be fine.
Also if you are contributing to other projects which could be using tabs, there are plugins that will detect if the indentation is spaces or tabs and when you press tab automatically inserts spaces or tabs accordingly
1 -
Be humble. Nobody knows everything.
Keep learning: read books, take Pluralsight courses, go to meetups.
Write unit tests for your code. No really! Write unit tests for your code!
Learn what the SOLID principles are.
Your job does not define who you are, you define who you are.1 -
Unlike biology, our field is dynamic! Things keep changing often.
So, no matter how much u already know, keep learning always!!
Never stop learning!! -
Invest in a good pair of noise cancelling headphones.
Ancillary: Have an "emergency" pair that you leave at your work desk for those times you forget your good headphones.1 -
Explain why a feature or request is a shite idea to your manager but don't accept 'well that's what the client wants' as an answer. Insist the useless manager twat should earn his money and not ruin the project.
-
If you're working on integrating a 3rd party app, never trust their docs to be fool-proof. Not only are they erroneous, they keep changing too. Better try it and ask questions on their forums, even if it involves a little more effort and time.
-
Don't spend all your time learning new languages or else the knowledge won't stick. Master one thing first, and then move on.
-
My advice from a very beginner dev myself is to take walks and use some fresh air. Dev outside your job on techs and frameworks that aren't use by your company. Sleep. Stackoverflow.
-
Well... best thing you could do is not limit yourself to one language and one area of programming. Experience and being better comes from exposing yourself to variety of programming areas and seeing how things are done there. :)
-
Advice to new devs: be open minded and adapt to the way things are done at your new gig. Be humble, things that aren't the way you're used to aren't necessarily bad (even bracing style and editors). Have a guru and absorb all you possibly can. Don't be afraid of showing that you don't know yet.
-
Practice by coding solutions for different types of problems. http://freecodecamp.com got good challenges and a great community (in my experience)
-
Please don't ask another dev what he's doing after he refuses to answer twice... Just gtfo if you see he's busy.
I didn't mean to be harsh but that's how I feel. -
While windows is fine and dandy for slacking off, you're going to need Linux or macOS to actually get work done.2
-
Always ask "can I Google this?" before interrupting a coworker, teaches you independence, often gets you an answer quicker, and makes you look smarter
-
Don't spend your time trying to learn everything you need to know by reading books or watching videos. Anything you don't use immediately you'll forget and it'll go to waste. Instead, learn the bare minimum required for getting started and make stuff! After writing some buggy spaghetti code that somehow works, you're ready to read/watch some more. Then rinse and repeat.
-
Start with C as first real programming language. It might have a higher entrance barrier but in future you'll blaze through new languages with ease4
-
Don't intentionally discard data you can not recover from at least 1 other source. Log everything. Disk space costs less than critical data loss. Especially important working with server to server systems.
-
Please do not send an entire stack trace asking how to fix something unless you've absolutely made the effort to solve or atleast google it.
-
Don't fall into frivolous arguments about tabs/spaces or brace style. It doesn't matter. But please make sure your code is at least formatted in a *consistent* manner - everyone else that reads your code will thank you.1
-
PHP: Laravel, Phalcon, Composer
JavaScript: Node.js, Express.js, Restify, Sequelize, AngularJS, React, npm, bower
Python: Django, Flask, Requests, pip, SQLAlchemy
Java: Spring, Dropwizard, Hibernate
DB: MySQL, MariaDB, PostgreSQL, Cassandra1 -
For all JS Frontend Developers: Learn to use the Developers Tools. Use Breakpoints and the Stack for Debugging.
-
Publish your code on GitHub or any other platform, when you can. It will serve as a resume and your work can help others.
-
Don't underestimate the powers of adding comments here and there. Your future self (or other devs) will be thankful.
-
Don't call yourself a 'dev.' Its oversimplified and doesn't really mean anything. Figure out what you actually do and call yourself whatever that is.1
-
Never be afraid to learn. Learning is the stepping stone of every developer, whether he/she started a week or centuries ago, never stop learning!
-
Have patience. Learning is slow at first. But once you get a hang of things, it feels like painting on a canvas ^_^
-
You may have the latest IDE with all the cool interactions and what not, but knowing how to use either Vim or Emacs on the command line will take you super far in your dev career.
-
Test your code. Take extra time to do self-review. It'll improve your code quality and position within your peers.
When you enter that "minor change-trial-error" phase. Go to sleep or take a long break. You're loosing time and adding more work to be reviewed and corrected later -
Do your research on the company you're applying for, and make sure they can give you the proper learning environment and experience. If they can't, fuhget about it. You gotta end up in the right place.1
-
Keep your stuff up to date. always!
It'll save you a lot of work & headaches and time. and we all know, time=€€ so it might even save money.
Besides that it is just cool and very nice to work with the newer things -
If you have to "force" code to do your bidding, your idea on how this should work might not be the best one. Sit back and reconsider.
-
How about: learn SQL. And I mean windows, CTEs, the whole nine yards. It's too easy to slip into abstractions (ORMs).1
-
Have fun with it and don't take it TOO seriously. Always look at a bug as a puzzle then you'll enjoy it more in the long run.
-
"Service is Service" don't take crap personally when there is a deadline looming people will react in different ways, people will blame you for things that are not your fault, people will swear at you, they will try to devalue you to make you feel bad about yourself and then regret it later if you take it personally it will play on your mind and make you ill don't make yourself ill if you mess up fix it messing up is what staging is for.
-
Hit Compile and Run almost as many times as you press any other key. Mid-writing tests work well as long as you understand what you're looking for!
-
And don't fck up the rest of your life...
There are a lot more fun things not only programming. Enjoy -
Choose tools that fit the task, don't force your task to fit the tools. Don't be afraid to leave your comfort zone, because for a good mechanic every screwdriver is useful.
-
Never proclaim to be an expert even if you become really proficient in your field. There will always be someone who has read a white paper that you haven't that will shoot you down.
-
Always keep pushing your boundaries.
Don't stay too long on anyone thing
i.e. Keep learning new stuff once you are confident about the old stuff.
Don't worry about the language, pick up one and get started. -
Start learning to code with a project that is close to your hard, will make time fly and you'll learn to code much better in the same go.
-
Not exactly a tip but do you know an app for quick-testing your skills in js, for intermediate-level, but with questions that are not too complicated (not code golf, though I like that too) so one can use it when commuting for instance ?1
-
Try to fix things yourself before you bug your seniors. But dont spend too much time if you're stuck.
-
Learn git. Contribute to open source projects - you may learn more from code review on a single PR than from a whole tutorial. Ask questions constantly. Learn more git. Look for the cleanest solution to a problem. Write code that is easy to improve, easy to expand, and easy to debug. Learn even more git. Don't limit yourself to thinking only in terms of OOP, or functional, or procedural, or whatever type of programming you may be comfortable with. Don't be afraid to do some work by hand. Learn git, so that when all comes crashing down and your team crumbles to pieces, when your relationships fail and your friends disappear, when you're down on your luck and there truly is no hope left in life, you can check out of the dangerous world of your current HEAD and return to the home and comfort of your master branch, which you've kept safe, secure, and functional.
-
Don't worry too much about understanding something (as in a language feature) 100% before moving on, as you use it you'll figure out how and why it works
Top Tags
Weekly Rant
View