AboutCS Student in UI
Joined devRant on 12/6/2016
Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:
1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.
2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)
3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.
4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.
5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.
6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.
7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.
8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.
9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)
10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...
These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!198
Just got a reply from a client complaining that the site I did for him is "too responsive".
Never got this kind of complain.
Normally I might get some complains about the site not being fully responsive but never was I expecting to receive a "site is too responsive" complain.15
Here's my piece of advice for new devs out there:
1 - Pick one language to learn first and stick with it, untill you grasp some solid fundamentals. (Variables, functions, classes, namespaces, scope, at least)
2 - Pick an IDE, and stick with it for now. Don't worry about tools yet. Comment everything you're coding. The important thing is to comment why you wrote it, and not what it does. Research git and start using version control, even when coding by yourself alone.
3 - Practice, pratice and pratice. If you got stuck, try reading the language docs first and see if you can figure it out yourself. If all else fails, then go to google and stackoverflow. Avoid copying the solution, type it all and try to understand it.
4 - After you feel you need to go to the next level, research best practices first, and start to apply them to your code. Try to make it modular as it grows. Then learn about tools, preprocessors and frameworks.
5 - Always keep studying. Never give up. We all feel that we have no idea of what we are doing sometimes. That's normal. You will understand eventually. ALWAYS KEEP STUDYING.9
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
Roughly 180 days, 5 months and 29 days, 4,320 hours, 259,200 minutes, I devoted myself to a client project. I missed family outings with my daughter and my wife. People started asking my wife if we had broken up. My daughter became accustomed to daddy not being around and playing with her. Sometimes only sleeping 4 hours, I would figure out solutions to problems in my sleep and force myself to wake and put them into action. My relationship with my wife became very fragile and unstable. I knew I had to change but I just needed a little bit more time to complete this client project.
Finally, the project was ending there was light at the end of the tunnel. I “git add –-all && git status” everything looked good. I then “git commit -m “v1.0 release candidate && git push beanstalk master”
I deployed the app to the staging server where I performed my deployment steps. Everything was good. I signed-up as a new user, I upload a bunch different files types with different sizes, completed my profile and logged out. I emailed the client to arrange a time to speak remotely.
“Hello” says the client “How are you” I replied. “Great, lets begin” urged the client. I recited the apps url out to the client. The client creates a new account and tries to upload a file. The app spews a bunch of error messages on the screen.
The client says
“Merlin – I do not think you really applied yourself to this project. The first test we do and it fails. If you do not have the time to do my project properly please just say so now, so I can find somebody else who can”
I FREAKED THE FUCKOUT on the client!!!!!!! and nearly hung up. My wife was right next to and she was absolutely gobsmacked. I sat back and thought to myself “These fuckers don’t get it”. All that suffering for nothing!
Thanks for reading my rant….
BTW: I did finish the project, the client was amazed on how the app worked and it is has become an indispensable tool for their employees.19
Love working with atom using this theme in coffeeshops, making people think I'm a top hacker, when in reality I'm just stuck with css classes or something. Equally stupid.25
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
Our CTO has been told, this morning by management, that our development department is "too quiet" and that it's spoiling "the atmosphere" of the office space.
So we've ordered mechanical keyboards.21
Finally I found a webpage related to my bug.
The page is from 2004.
"Yes, yes! This is exactly the problem I'm having"
*Carefully reading each comments*
*Looking at scroll bar with stress*
*Almost coming to end, no signs of solution*
At the end the thread creator say: "Ah finally I've fixed the problem. Thanks everyone for helping"
*moment of silence*
WHY U NO SHARE THE GOD DAMN SOLUTION? YOU FUCKING IDIOT17