If I could tell every single developer one thing, it's that there are more people using accessibility settings than they know. A huge chunk of users have the text size turned way up, are using screen readers, or can't get the sound the way the dev intended.
But I'd also like to tell everyone that regex can save them so much effort.
Oooooh oooh I'd also like to teach them a simple Unix search...
Okay, what's one thing YOU would tell every single developer, senior or junior, in the tech industry?
Top comments (9)
That software spends most of its lifetime being maintained. Therefore, investing in writing code that's easy to read is more important than just getting the feature to work the first time.
On a related note, code can only be so "self-documenting". A paragraph explaining how the system works can save someone hours of trying to figure out how it works by reading the code.
Brilliant. I was prepared to comment the exact same thing. As a learner who tends to read lots of code, I have come to realise that readibility and proper documentation might be some of the most important traits of a really educated programmer.
I love both of these. Absolutely yes.
Keeping it simple is way underrated. It’s great to dig in and learn a new thing by diving deep, but ultimately the more simple you can keep your solution, the better off you’ll be in the long run. I often recommend using time-boxing techniques (for myself too!) in order to make sure we don’t go too far down complex solutions.
100%. I tend to over-engineer things more frequently than I'd like to. I'm slowly but surely getting better at catching myself sooner rather than later, but I still find it tricky.
Do you have any advice for detecting when it's better to invest some time trying to find a simpler solution? I find this especially difficult after spending weeks to come to a solution and still feeling like it's more complex than I'd like it to be.
My recommendation is to start simple and go from there, rather than the other way around. Only build what you need now. Only write the code that fixes the problem. Then optimize/refactor later if necessary and if it will be of benefit (i.e. if it's throw away code for a prototype maybe you don't need to refactor and optimize).
I recognize that some of this comes with practice and experience, so if you still feel yourself going down the rabbit hole, the first step is catching yourself! As I mentioned, timeboxing can be helpful, too. For instance, give yourself an hour to try out a new approach or to figure it out yourself before asking for help.
I also gave a talk on this very subject, which you can watch here: Shiny objects are cool, but so is building products people use
Definitely better or stronger focus on communication skills :)
dev.to/leogopal/4-simple-tips-to-b...
Estimations will never be accurate enough.
The best developers look up and see how everything works beyond the small part they're working on.