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
-
Developers, with big egos? Never! Great advice. Thanks for sharing @purged
-
This is pretty good, I share the sentiments here. A couple of my own to add here:
- spending some time on upfront design is important. It's also important to realize that you will not catch all issues upfront, and you will have to tweak your designs as your go along.
- don't do stupid work. If it's repetitive automate it.
- your best code is the code you won't have to write and maintain.
- whatever you do, make sure you actually solve a real problem, so have realistic metrics to estimate your success.
- you are never the smartest person in the room. corollary: feedback is always important, the earlier you get some the better.
- spend time to have deep understanding of the issues/technology
- don't jump aboard the hype train. Counterargument: stay atop of new trends.
- use the right tools for the job. This applies to different abstractions as well: code, services, your home. -
@renegade When a client asks for an ETA on a bug, I set my status to "Away."
No, truthfully, that is my weakest area. I have never been any good at estimating time.
I typically tell them "It will take me some time to diagnose the issue. Until I know why it's broken and come up with a plan of action to resolve it, any ETA I give is a shot in the dark."
Any good technology leader should play top-cover for you with generic statements like "We're looking into the bug as we speak and will get back to you on an ETA as we know more." -
@purged to add to this, it's always good to add extra time, if you think it will take 6 hours to fix, give yourself 10-12 hours, if you get it done early cool clients will live you, if it overshoots they won't know
-
@JBSnorro you can 'favourite' the rant. Under your profile you find all your favourites.
-
@phiter remember, ego and confidence are two very different things.
Confidence looks like "I can handle that!"
Ego looks like "I can handle that better than you!"
With ego often comes the inability to take constructive criticism, which makes nobody want to work with you.
I too am self-taught. I too had ego issues. Once I learned to accept the fact that there ARE developers who are better than I am, I felt better, and my coworkers liked me more. This is one of the tips that I can tell you I learned the hard way.
Sometimes ego is useful to give yourself confidence, but when that ego is thrown in people's faces, they'll resent it/you. -
@piks Agreed, @purges you should definitely write that on Quora or/and on Medium or/and Hashnode.
-
I would add, don't treat older coders who aren't updated on the latest hot framework, library, API, technique, etc. like garbage. None of us knows everything, some of us are re-entering the programming workforce, and each of us gets through a learning curve at different rates with different learning styles. If you are condescending to or talk about older developers behind their backs, it will come back around on you some day.
-
@stackodev I think, if you talk about any coworker behind their back, regardless of time or skill, you're a problem.
That said, my personal opinion differs slightly. Sure, we don't and can't know everything about every framework/language/technology out there, but regardless of whether you're an "older" dev or not, if you don't immerse yourself in current tech and trends, you are allowing yourself to become obsolete. Us "older" devs don't get a pass when it comes to relevance. Quite the opposite really, we should be setting the example. -
@purged thanks man!
Can you also give some advice on how to document your software? What is practical?
Thanks in advance 👍 -
I have also been doing this for 20 years. Love the advice except for 2).
I think you should ask lots of questions but
a) think about what the answer to your question might be so you can validate your thought process against the more senior members of the team
b) listen to the answer - write it down if it will save you asking it again -
@purged
Thank you for sharing and mirroring your behaviour to the community.
I believe you being a true plus value to all your surrounding.
That makes you a role model to me.
Thx -
@timurtu I guess it's just the peril of working with individuals. For my part I try not to be persnickety when someone offers to help me. If anything I feel self-conscious and awkward asking younger developers to help me with stuff they likely assume I already should know. Nobody can know (or remember) everything, though.
-
#1 applies even more so for senior devs! If some dude asks me a question, I'll take a break and help them. I do c++ and in my case I have a very different idea about documentation: code is the documentation, I document unobvious/tricky things and some APIs that are meant to be used by others, other than that I try to keep code dense and not polluted by BS comments that do not have any value.
-
For juniors I'd also give this advice:
- your boss/manager is not your friend. Don't be fooled.
- always work on self improvement and some personal side projects at your personal time.
- always be looking for better opportunities. Early in your career if you stayed more than 2-3 years at the same place switch to active mode of searching for a better place. Remember: making the right move may advance your career in a day to a new level whereas it would take you 5 or more years of your life to reach the same level at the old place. -
Regarding ego/asshole attitude: even if you are much better than your teammates don't act like asshole, try to help them instead so that they become better. In the end, the better your teammates the easier it is for you. Also, many companies specifically try hard to avoid people with ego issues and assholes, regardless if they are gods of software engineering. In interviews we try to spot these types of people and reject them if they are suspected of such ego problems.
-
I would like to add one tip that seems important.
No matter what, if your boss/employer tells you to do something in a certain way and you think its not the best approach to it, don't be afraid to give your opinion about it, sometimes they don't have a clear/better picture of how to accomplish X task, it is important that as a developer you can speak your mind out and then agree on both sides.
Sometimes my coworkers just follow my orders as literal as I said them, but they never put some effort on questioning me because they think I am correct all the time.
I let them know to always tell me if they think my approach is wrong or good, so we can discuss it and finish our work in what we think is the best way of doing it. -
I have archived some of my favorite rants @ https://devzin.xyz
Your this rant has been added. Please let me know if you want to remove it from there.
(I hope you don't :3 ) -
@Cloudless-mind welcome buddy
-
I am 14 years old right now, and I am currently practicing and learning Java on Udemy. This rant literally made me imagine what it would be like to be in your shoes, a 20-year Software Engineer with loads of experience yet still humble enough to not be a jerk about their work and state how its the best. I wish there was a way (im new to devRant so idk) to save a rant so I could see it any time I wanted. Love this thing man and congrats on the years of work you put into what you do!
-
I will agree with all of this. In my previous company, a new guy joined after I left. I heard that he was very good and everyone seemed to have a positive impression of him.
The only person who did like him was the senior developer. I came to know that despite doing the tasks he was assigned, he was the code he wrote was unreadable and kept pestering the other developer.
Just because no one saw under the hood for the code. He was considered good. -
You passed on a good dev because they didn't bother to learn the particular version of the language you are using, while they know an earlier one?
I can't study every language out there, especially something as ancient as PHP, so I study whatever language I need on the job. Switching languages is easy. Please send those devs you rejected my way. -
Regarding Item 2 - about asking senior devs questions "before interrupting them, exhaust your resources".
Sometimes I'm kind of upset when I find out a junior dev has spent a long time on a problem when they could've just asked me first.
If the question is something as simple as "how do I sort an array by a property in the items?" obviously that's something they should google. BUT with some junior devs it's sometimes dangerous to let them sit alone for too long. If you let them ask their array question you can counter with "why do you need to sort the array?" and it might turn out that they just THOUGHT they needed to do that, but actually that's not at all what they had to do. Maybe they just wanted to select one item from the array. Maybe they didn't even need an array to begin with.
There are so many things which a junior dev can get wrong and if you leave am alone for too long they might dig a rabbit hole where they've used 2 libs to sort an array they didn't have to sort -
@jiraTicket you're absolutely on your point of view. We need to take care of the junior devs so they don't go into the wrong direction.
But (giving my 2 cents on this) it's also true that junior devs (and as a matter of fact we all) need sometimes to learn HOW TO NOT TO DO THINGS and you only learn that DOING THAT; going on the working direction sometimes. At least you've learned one way that doesn't work that could help, down on the road, so identify similar situation and take a better decision (maybe not the right one).
So, like anything in life, there must be a balance between "find a solution" and "guidance". -
@fmarcelinopt True!
I’ve been a mentor for 2 juniors and I struggled daily with deciding between letting them learn by doing (fall down rabbit holes to fail and grow til next time) - or stopping them before they went too far.
I found that it was quite individual. One of them didn’t really learn much from their own mistakes - but was like a sponge when seniors told them the ”answer / best practice”.
The other was the opposite - didn’t consider why best practices existed until they got to try all the way with a mistake and feel why it failed.
Was really hard to tell based on their personality who turned out to be which type, so I still didn’t learn that much about mentoring in general 😔
But the one thing they had in common was that they benefited from explaining to a senior why they wanted to do something a certain way -
As a jr dev who already has embraced most all of these tidbits (being retrained near my 40s helps in a lot of this :P) I have another
Be willing to throw it all away and start over. You get attached to what you did and start trying to fix it rather than walking away and seeing if your initial premise was flawed you will just continue to throw good money after bad.
sometimes the only real fix is to take what you've learned and start over. This isn't failure. This is iteration, and its core to good code/products.
(and TDD/BDD !!! I can't stress this enough - even if you don't end up using it, having the knowledge under your belt helps you think of more edge cases and more concerns!)
!rant
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!
rant