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
-
"Don't give your 100%. Never. Once you gave, managers will start expecting more than that." - My mentor.16
-
(Q: How much are you allowed to Google as a developer?)
“You’re allowed to Google as much as you want. This is not school, you’re employed to solve a problem. Nobody cares whether you Google for the answer or remember the answer from another Googling.”15 -
"Engineers don't memorize documentation. They know how to use it."
Programming felt insurmountable to me before I started with it. This phrase blew my mind and changed my approach entirely.3 -
I wasn't going to post this because I expected loads of hate but fuck it, I'd rather share it anyways. Also take into account that sometimes there's no choice because money is needed or other circumstances :)
This one guy told me to never let down my values and what I stand for if I can afford to do that, no matter what they are.
I'd quit my job over having to use tools like Google or Slack (luckily my company is highly against using Slack and most people have moved to ddg) and as for WhatsApp, I said at my interview that I'd either wanted a business phone for using WhatsApp or I wouldn't use it. Boss said 'thats cool!'
I quote from him(that person who said this to me):
"they force you to use something you're uncomfortable with? Fuck'em. They don't understand your reasons? Their problem.
Even if nobody in the entire world understands/accepts your reasons, doesn't mean they're not valid."29 -
"But I don't know where to start..."
"... just start typing, be willing to mess up, and if you get lost just start over with better understanding from messing up. Eventually it'll work."1 -
1. Humans perform best if they have ownership over a slice of responsibility. Find roles and positions within the company which give you energy. Being "just another intern/junior" is unacceptable, you must strive to be head of photography, chief of data security, master of updating packages, whatever makes you want to jump out of bed in the morning. Management has only one metric to perform on, only one right to exist: Coaching people to find their optimal role. Productivity and growth will inevitably emerge if you do what you love. — Boss at current company
2. Don't jump to the newest technology just because it's popular or shiny. Don't cling to old technology just because it's proven. — Team lead at the Arianespace contractor I worked for.
4. "Developing a product you wouldn't like to use as an end user, is unsustainable. You can try to convince yourself and others that cancer is great for weight loss, but you're still gonna die if you don't try to cure it. You can keep ignoring the disease here to fill your wallet for a while, but it's worse for your health than smoking a pack of cigs a day." — my team supervisor, heavy smoker, and possibly the only sane person at Microsoft.
5. Never trust documentation, never trust comments, never trust untested code, never trust tests, never trust commit messages, never trust bug reports, never trust numbered lists or graphs without clearly labeled axes. You never know what is missing from them, what was redacted away. — Coworker at current company.9 -
"Never undervalue yourself or let anyone else undervalue you."
"Learn to say no."
Same person during my first contract, where I was working insane hours for very little pay. -
Always multiply your time estimate by Pi (an Irrational number). That way you're guaranteed your estimate will be irrational! (Just like the clients expection :P)3
-
Try not to use floating point numbers in places where precision is important. Like for instance, money. Always store the base value where it makes the most sense
15 -
"Only stay late at work when it makes sense to, otherwise always leave on time. There's always going to be work left, no matter how much you get done in one day."
Best advice ever.
Edit: I have to say it was during my first week in my first recent grad job.2 -
“Yeah, the database password has to be ‘password’ or the code won’t work”
—My PM
Note: I don’t actually believe this to be good advice.1 -
"Stop working from home. Fuck this. We do enough and don't get paid what we should. It is you and me for two campuses and you are far more knowledgeable and qualified than what they offered you at the beginning. I get that the benefits are killer but don't burn yourself out. I am not expecting you to work from home. Will not ask of it unless really is required and would much rather we have a few beers instead of getting together to finish bullshit deadlines...for 2 devs"
My current lead developer. He turned into my work best friend and he is really into the whole concept of "fuck it we ain't getting paid enough"
Dis b ma dude.2 -
Always be humble and always keep learning. No matter how good you get, there is always some better.4
-
Before you start to code write your ideas on a piece of paper ... Everytime I beginn a project I start with coding, this advice is to difficult for me 😂5
-
I was on the verge of a nervous breakdown due to all the pressure at work, and my boss sat me down one day and said "Don't take it so personally, it's only work".
He explained that you simply cannot make all the people happy all the time, you can only do your best, and that is good enough.7 -
Do NOT build something as fast as possible. You are going to end up spending more time trying to refactor the mess than youd have spent drawing a class diagram.7
-
The sooner you start coding, the longer it will take.
This was meant as a way to tell us all the slow down and plan first. If you go right into coding things before the structure is thought out you will end up with garbage code.4 -
"Put aside your ego, it's the worst problem with programmers" -My mentor
I tend to help others and contribute with courtesy, putting my ego aside and listening to others' suggestions at all times, no matter how potentially silly they are4 -
Thanks @dfox
As a junior,
This week's topic is giving a lot of best advises to me from other devs..2 -
There is no reasonable excuse for doing anything less than your best.
- Robert C. Martin, Clean Code4 -
"Don't be too cooped up with work. Your work will always be there, unending. But your free time with family, friends or just for yourself - that's limited."
-
Don't be stressed about day-to-day challenges/problems. They'll mean nothing in one year or even one month. But the health damage caused by stress will stay with you.2
-
"Unless it's the big red button with launch codes, there are no buttons you can press that I can't unpress"
Translation: you have to TRY to mess up so bad it's beyond repair.4 -
Wk103 got to be the best weekly rant, it’s like everybody sharing a good quote about programming, and it’s useful
-
- Premature optimization is bad and wastes your time
- You need to see the big picture
- Always add extra hours to your estimates
- Test your feature like a QA engineer; look for the edge cases2 -
Well that was a good little time off :)
Decided to go offline for a little and that was a good one, hello again.
Wrote a geoip service because I hate rate limits and such so fuck it, why not write one myself (data is not that accurate as it's free but quite alright if you ask me) (front end still fucking sucks).
So yes, that's I guess :P13 -
“Don’t learn multiple languages at the same time”
Ignored that. Suddently I understood why he said that. Mixed both languages. In holiday rechecked it and it was ok.
Sometimes mistakes can lead to good things. After relearning I understood it much better.
“Don’t learn things by head” was another one. Because that’s useless. If you want to learn a language, try to understand it.
I fully agree with that. I started that way too learning what x did what y did, ... But after a few I found out this was inutile. Since then, I only have problems with Git
Another one. At release of Swift, my code was written in Obj-C. But I would like to adopt Swift. This was in my first year of iOS development, if I can even call it development. I used these things called “Converters”. But 3/4 was wrong and caused bugs. But the Issues in swift could handle that for me. After some time one told me “Stop doing that. Try to write it yourself.”
One of the last ones: “Try to contribute to open source software, instead of creating your own version of it. You won’t reinvent the wheel right? This could also be usefull for other users.”
Next: “If something doesn’t work the first time, don’t give up. Create Backups” As I did that multiple times and simply deleted the source files. By once I had a problem no iOS project worked. Didn’t found why. I was about to delete my Mac. Because of Apple’s WWDR certificate. Since then I started Git. Git is a new way of living.
Reaching the end: “We are developers. Not designers. We can’t do both. If a client asks for another design because they don’t like the current one tell them to hire one” - Remebers me one of my previous rants about the PDF “design”
Last one: “Clients suck. They will always complain. They need a new function. They don’t need that... And after that they wont bill ya for that. Because they think it’s no work.”
Sorry, forgot this one: “Always add backdoors. Many times clients wont pay and resell it or reuse it. With backdoors you can prohibit that.”
I think these are all things I loved they said to me. Probably forgot some. -
*Never* do CSS tweaks over the phone and tell the customer to refresh and approve the change. This will lead to endless tweaking andlong calls at any hour, and further trivializes your work by making it look like everything can be done instantly. Better to have them send you the changes they want, then send them an update later once they have been done—perhaps with a bit of a delay to further stave off the sense of instant gratification.
Also, if they keep requesting changes to changes after you’ve done what they asked, be prepared to let them know that future changes will incur an additional fee. -
I'll use this topic to segue into a related (lonely) story befitting my mood these past weeks.
This is entire story going to sound egotistical, especially this next part, but it's really not. (At least I don't think so?)
As I'm almost entirely self-taught, having another dev giving me good advice would have been nice. I've only known / worked with a few people who were better devs than I, and rarely ever received good advice from them.
One of those better devs was my first computer science teacher. Looking back, he was pretty average, but he held us to high standards and gave good advice. The two that really stuck with me were: 1) "save every time you've done something you don't want to redo," and 2) "printf is your best debugging friend; add it everywhere there's something you want to watch." Probably the best and most helpful advice I've ever received 😊
I've seen other people here posting advice like "never hardcode" or "modularity keeps your code clean" -- I had to discover these pretty simple concepts entirely on my own. School (and later college) were filled with terrible teachers and worse students, and so were almost entirely useless for learning anything new.
The only decent dev I knew had brilliant ideas (genetic algorithms, sandboxing, ...) before they were widely used, but could rarely implement them well because he was generally an idiot. (Idiot sevant, I think? Definitely the idiot part.) I couldn't stand him. Completely bypassing a ridiculously long story, I helped him on a project to build his own OS from scratch; we made very impressive progress, even to this day. Custom bootloader, hardware interfacing, memory management, (semi) sandboxed processes, gui, example programs ...; we were in highschool. I'm still surprised and impressed with what we accomplished.
But besides him, almost every other dev I met was mediocre. Even outside of school, I went so many years without having another competent dev to work with. I went through various jobs helping other dev(s) on their projects (or rewriting them), learning new languages/frameworks almost every time: php, pascal, perl, zend, js, vb, rails, node, .... I learned new concepts occasionally (which was wonderful) but overall it was just tedious and never paid well because I was too young to be taken seriously (and female, further exacerbating it). On the bright side, it didn't dwindle my love for coding, and I usually spent my evenings playing with projects of my own.
The second dev (and one one of the best I've ever met) went by Novo. His approach to a game engine reminded me of General Relativity: Everything was modular, had a rich inheritance tree, and could receive user input at any point along said tree. A user could attach their view/control to any object. (Computer control methods could be attached in this way as well.) UI would obviously change depending on how the user could interact and the number of objects; admins could view/monitor any of these. Almost every object / class of object could talk to almost everything else. It was beautiful. I learned so much from his designs. (Honestly, I don't remember the code at all, and that saddens me.) There were other things, too, but that one amazed me the most.
I havent met anyone like him ever again.
Anyway, I don't know if I can really answer this week's question. I definitely received some good advice while initially learning, but past that it's all been through discovering things on my own.
It's been lonely. ☹2 -
'Be long-term lazy.'
As in:
Work hard.
DRY.
If it takes more than 20 minutes, then automate it.
Prevent repeated work by testing just enough.1 -
If it's worth building, it's worth testing. If it's not worth testing, why are you even wasting your time building it?1
-
“Get the code working first, then worry about how to clean and optimize it.”
For me when I learnt about optimization and how one thing was better than something else, I tended to focus on that. I’d have a picture of that in my mind, and would try to write as clean of code with less hacks in the middle and as optimized as I could in the first go, which slowed me the way fuck down.
After he said that to me, I realized I was stupid and just wasting time if I worried about that from the start. Would waste time, and just cause more headaches from the start than it was worth.
——
Oh also another one, I knew never to trust the client from the start but the way he said it was funny. “Never ever trust the fucking client, don’t trust them with anything. I trust Satan more than I trust the client.” 😂7 -
I'd say one of the best advice a dev gave me, was that, I should not write duplicate code, but rewrite these parts to a single function.
And another one: If you use specific values in the code, instead of putting it in multiple places, assign it to a variable at one place and use the variable later on.
These advices sound quite trivial, but I think every beginner should learn these as eary as possible.
Boiiii have I seen shitty code from people who don't give a hobo's ass about maintainable code.
Be a good coder.
Write for quality, not quantity.
Care about your successor.
Thank you.
If not, I will fucking find you, fill your guts with napalm and light you up alive on a rusty pole while laughing hysterically.1 -
"Never trust a user or client, when dealing with 'bugs', always try to reproduce."
very useful advice from an old colleague1 -
"This pub is famous for its pork dishes. And I usually buy liquor from that stop, quality approved."
- one dev friend
// said "best advice"
// not "best dev advice"2 -
IE is crap. Use Firefox.
Amazing that it still applies to this day, except maybe swap Firefox with Chrome, depending on preference.12 -
Me: Asking a lot of junior questions
Dev: Stop! Before you ask another question - think for 10 minutes, google another 15 minutes and if you don't find anything - ask me.
^ This was the best thing he said, after that I can google pretty much anything, and hell, I even go to 5-th page of the google from time to time!5 -
Never update prod stuff on a Friday afternoon.
After the team lunch.
With cheese fondue and white wine.1 -
For any complex project start simple by doing the MVP (minimum viable product) then build on it and change it until it reaches what you want in time.
-
The best dev advice that I had was when Google Apps recommended me DevRant, related to the apps I had installed. I learned so much since them.
-
"Don't try to memorize everything, after you've coded for a while you'll start remembering it, even the best devs Google shit ALL THE TIME."3
-
- draw/write down your problem, You'll pretty much guarantee that you'll find the solution.
- don't overcomplicate how you program, do what works for you. -
During my first year of working, I was offered to work part-time at another company. I actually took it to my supervisor and asked for his advice.
He began with a sigh, he knows that I like programming so much and wants the job because I wanna do more programmings. He gathered his thoughts and said calmly, "Look, I cannot stop you if you want to, but think about this, you already are doing programming for five days a week here. Take those extra times you have to develop other parts of yourself. Go learn public speaking or something" or something along that line.
I gave it a deep thought, took the advice, and rejected the offer. I eventually went on to commit myself on volunteering for the next two and a half years, and secured a promotion about a year from that conversation because my supervisor sees improvements in my communications with others and my soft skills in general (unlike programming, you can't volunteer in an organisation without speaking to people).
Sometimes we programmers only wanna code that we forget that what we're building are for humans and involves other humans. You wanna be the best at work? Try to grow on your horizontal axis, too.1 -
Not particularly advice, but taught me Git, React, Node and bought me pizza whenever I succeeded in a task3
-
If you're good at the debugger it means you spent a lot of time debugging. I don't want you to be good at the debugger.
- Uncle Bob2 -
"Google it" and "don't be afraid of complex code, someone wrote it" - A fellow student at the time.2
-
"The first 90% of a development is done in the first 10% of your estimated time schedule and the last 10% is done in the remaining time"4
-
[...] we should never ignore any part of code. The parts we ignore are where the bugs will hide.
- Uncle Bob1 -
I was underpaid and doing a job I didn't really like, I stuck with it for 6 months and told my boss about it. He didn't do anything about it. Our head of department told us at a meeting that as a young professional, you own your career path. I quit the following month and all of a sudden, my boss was ready to listen to him. I told him it was too late, I own my career path and this isn't good for it.
-
!$rant
"Always make sure to have good documentation in your code."
And I still struggle with this advice xD -
Best advice a dev gave me? So much/many over the years.
I shared this one just last week to another dev..
"If you are writing a lot of code to do something, you are probably doing it wrong."
- Marco Cantu - Borland Dev Conference -
My manager asked me to have colleagues outside engineering dept test an interface for a personal project in order to get the best feedback on UI/X
-
Abstract anything dealing with external services where if they go out of business, change their internal policies, or you get a wild hair up your ass you won't have to change your entire code base later.3
-
Ignore the official start/finish times. Instead, sync your office ours to that of someone in your team you respect.4
-
Dev friend: Happy in your job?
- Me: Kinda, don't see myself doing it for another 35 years tho.. :(
Dev friend: Go back to school, learn computer sciences and get a dev job. You'll love it.
So now I'm back in school, no regrets whatsoever. Without a doubt best advice.. :) -
Once a fellow dev gave me the advice of always questioning the enhancements and fixes that are asked to be done. She said i should always ask things like is this a legitimate enhancement asked for by the client? Is it really required? Will it alter any existing established flow of our system? Etc.
At least I found this helpful because it saved us a ton of unnecessary work that would later have to be rolled back. -
Beware of scope creep. If it's a bug, fix it for free. If it's a new feature or changed from the original signed off scope, charge for it.1
-
Whatever duration estimate you have on a project, double it. Better in the clients eyes that you finish early than scrambling for time toward the end or finish late.1
-
"Why don't you look for a new job?"
I have a monthly coffee meetup with an ex colleague, where we rant about each others frustrations at work. Since she used to be part of my team she knows everybody and can relate to my stories and updates. In short: she was the kick in the boot I needed to start looking, and after the summer break I'll start a new job making 45% more.2 -
This is not a direct advice but something I noticed sometime ago.
In a company I worked at, one of the more senior guys was working on task and stopped to ask the rest of the team about something related to that task. One junior guy offered to help and started explaining and I saw the senior guy listening carefully giving him his full attention.
The thing I took out of this is to listen to those around us even if they seem to have less experience. You surely will learn something. -
!rant
Best advice ever: "Why are you using Java for this? use Python"
And that kids, is how I fell in love. -
"Don't fall for the hype. A lot of ideas, groups and methodologies are basically cults trying to advertise their consulting services. While I have no problem with that, just remember that when you run into one of these guys and they are quick to shit on the alternatives to their way (and those who built them) to always be very suspicious."
Context:
We had the opportunity to meet 2 very bright people who were heads of their respective communities in a similar area. They were both talking a lot of shit, and getting kinda harsh.
A brilliant dev I worked with, who knew both people for years, took me aside and told me this.
Some cults have cool shit, just don't drink the kool-aid -
Not really Dev advice, but I appreciated it.
"Do your best to take responsibility for everything that happens to you. Even if it's not your fault."
"On the flip side, never apologize for something that isn't your fault. That includes other people's feelings. You're not in control of their emotions." -
"Your goal should always be, working on building things so tomorrow you don't have to worry about them... If you are being repetitive its time to reevaluate"
-
If you want it and there's no better alternative, make it.
This is what has driven me for the past few years as I've fallen hopelessly in love with programming. I'm my own creator; my own God, if you will. -
Cannot pinpoint one advice as the best but the comments of this rant are the most helpful one's
https://devrant.com/rants/1339948/...
@Floydian @AlexDeLarge @wokeRoach @Devnergy @sharktits @norman70688 Thank you guys for it. I often come back and re-read it.1 -
When you make fried eggs after you cook them abit put some water on them and then close them with a lid so they will cook evenly with the heat of the evaporating water
He was a python developer.3 -
If the client wants too increase the scope or change requirements, that's fine but put the difficult decision in their hands.
Do you want to delay delivery or drop something else. -
“Don’t forget to go home”
A solution architect when he looked into my team room at 6:30 and saw me still sitting there working. -
Best advice so far: "KISS: Keep It Simple and Stupid"
That works every time because your design of the code will be understandable. Your code must seldom to be refactored. You aren't that asshole who never comment and document anything. And the most important part: The code works as designed without flaws!4 -
I heard in one dev podcast saying "Know everything about something and something about everything". I think it's very good moto in your dev career and general in life3
-
"Be responsible for the commit you make" - One dev friend.
He told me that you could upload at any time (even on Friday at 5pm) if you are ready to stay late if the system gets broken. -
Never speak lowly about your profession or position to anyone. At best, no one cares. At worst, you lose an opportunity to improve that position.
Have pride in your work, irrespective of how much it sucks. If you don't have pride, pretend to while talking about it to others.
Rants are fun to read, but no one respects someone who rants about their own profession. -
Don't fix what ain't broken.
Alright.. that might not be 100% what need to be done at times, as other out-of-scope things tend to break these things too.
Nevertheless, if you fix what ain't broken,be sure to have it working before you switch over. -
Former coworker had a Post-It on his display:
"When in doubt look char by char"
Often a minor typo can give you a large headache, so this is a really good advice for those WTF moments where you thought the universe isn't working as designed.2 -
We all have that moment in life when we feel that people around us are just there to -use- you. Honestly it feels annoying when the majority does. My friends noticed that a lot of people used me to help in their tasks. I usually don't say no, I find every opportunity to be a learning one.
A friend of mine, after hearing our stories, said something to me that has ever since stuck to me:
"if people don't use you, you're useless".
Honestly, I find this to be one heck of an advice. Certainly has made me feel like I'm on the right track! -
From our CTO:
"As cheesy as it may sound, if you want things to change, you need to be the change"
I was able to build a team based on that, now our team is looked at as the "cool team" in the company.1 -
"Instead of writing classes in Python, create packages and use functions. Each function should do exactly one thing without being specific to the program you are developing." - Steve Waweru
-
Don't try and fix parts of the code that isn't 'broken' in the clients eyes.... You'll spend hours fixing something they'll neither appreciate or understand
-
The best dev advice a dev has given me is to write clean and structured code from the very start of every project. Changed my life in general.
"How you do one thing is how you do everything." -
Every person project cycle.
1.thinking 2.making bitbucket private repo 3.Making slack channel for contributors.4 Explaining the idea 5.the end.
I seriously need to work after step 5 -
All software tests are "rust free guarantees".
That it is to say, if your car manufacturer issues rust free guarantees, their cars are prone to rust, which means they are shyte.1 -
"You should never be working under someone who's not smarter than you. Unless one day you surpass me, then keep it up and don't tell anyone."
-
Don't get dependent on desktop apps. Learn to do everything on the command line. That way it doesn't matter what machine you're using.
-
As an -absolute beginner-, don't try to prove yourself by doing everything on your own after only a short explanation.
Rather ask as many questions as you need to finish it. One questions more now, saves 20 headaches later. -
"Write the failing test first."
Oh, I know. This is probably simple, but when you're stuck on support tickets - there's no faster way than to write a test for whatever the issue is and run it.
You wind up having a quick way to verify your bug fix and you now have a test going forward to ensure the bug never happens again. -
Everyone here is intelligent and capable. Everyone's opinion matters and anyone may solve a problem you struggle with.
-
- Understand programming and how the software work... then choose whatever programming language to build it, it is just Scripting after all.
-
“You want to survive and steps ahead from the others when you grow up? Learn english” - my dad
I’m from wkwkland and holy fuck it’s true. -
Never say you can't do feature A, offer a different(better, cheaper, faster, possible) solution when saying NO to your boss
-
My mentor to me when I joined the job fresh out of college (in a somewhat dramatic tone, which is why I remember it so vividly):
"Gone are the days when you wrote programs with a small number of big functions, and lots of comments. Write code which is easy to read by humans - small functions which do 1 thing and are named after the 1 thing it does."
TL,DR: well named modular code. -
Whenever there's a crisis I immediately slow down.
Get calm. That has to be step one, as long as it takes. Then (usually) the crisis is actually no big deal and there's a simple solution, but you'll never find that during panic mode.1 -
<sarcasm> best advice?
Write microcontroller code in C++ even if the underlying OS won't understand. You can always decompile the program to C code and use the generated code.
Things he forgot to mention:
- cannot use most of C++ core functionality (basically no STL, no exceptions, all of C++11)
- have to get your code to compile twice (C++ and C afterwards)
- debugging that generated C code is a pain in the ass
- have to debug twice -
When you’re frustrated and think you need another developers help, exhaust all of your resources before you ask. Google it, look for similar functionality in the app to mimic, ruminate for a hour. We are all working through challenges.
-
Learn git! Git and GitHub basically opened up my eyes to so many more possibilities and helped me manage my workload between two workspaces. It turned me into a person who sshed into a server someone lent him to code into someone who uses github for everything and who can manage between two or three workspaces efficiently
-
If you ever get tasked with something you don't know how to do, know that it is never your fault. The management, team lead or HR screwed up.1
-
"First ask the context of something and never why it's like it is"
I used to criticize bad code and get ratled by it... My mentor said this to me and added "sometimes it was made by an asshole and sometimes it has a reason"...
So, trying to find out if there's a reason for some of the shit I find and understanding their context helps me be better on dealing with my teams -
There is no shame in being tired of reinventing the wheel for every single project, and using a framework will make you save a lot of time
-
"Bug fixes and performance improvements" - what I actually mean is that I shipped some dodgy code & this patch covers my humongous arse...sort of.1
-
When you’re frustrated and think you need another developers help, exhaust all your resources before you ask. Google it, look for similar functionality in the app to mimic, ruminate for an hour.1
Top Tags
Weekly Rant
View