One liners that I have had difficulty in learning over multiple years :
A lot of people in my team are very good at finishing tasks in a short amount of time, and I am not. Reason being: I am a perfectionists when it comes to code. As a company you want to ask yourself "Is it worthwhile spending more time on code quality, or do we deliver tasks asap to the client?". After reading the book "Clean code". An important factor here is that it considers a large codebase system. Knowing this I strongly believe that code quality is way more important than some people think. Whether it concerns new features or improving some code on the sideline of a small bug, it's your responsibility as a developer to maintain code quality. The most difficult thing I still have a lot of doubts about is: "What's the maximum amount of time you can spend on a given task?"
Be pragmatic.
It is easy to get caught up in the idea of writing elegant/brilliant/perfect code. You can golf code down to a high performing, low footprint ball of random symbols that no one else can decipher and that's fun ... for a novelty site.
As developers, I think we often forget that at the end of the day this isn't about pleasing us or making our code look the best, but rather solving a problem and creating an enduring solution. We want software that works, that doesn't have defects, and is easy to maintain.
This means trade-offs. Optimizing a routine to shave off 9 milliseconds when it is part of a UI and the average user takes hundreds of milliseconds even to process and respond is probably a waste of time. Often we'll see a framework touted as "100 times" faster and switch even though it's 10x harder to work with. What do you gain? An imperceptible change in performance for higher cost and longer production cycles.
I was on another thread when someone made the blanket declaration "if statements are always a design flaw." Of course, instead of actually explaining why, they continue to maintain they didn't have to explain because it's just a fundamental rule of pure design and using them is wrong.
I know it may sound rude, but my hard lesson to learn was "so what."
Personally, I know no matter what level of developer is touching my code, this:
if (a > b) {
x = 'yes';
}
else {
x = 'no';
}
Is far more readable and easier to debug and maintain than this:
x = a > b ? 'yes' : 'no';
I may revel in the conciseness of my brilliant code, but what happens when I also have to set y? You could do this:
x = a > b ? (y = 1, 'yes') : 'no';
But what are you really gaining? I would posit not much. You don't need to compact your code, there are tools that do that for you. Why not make it easier to read and add space to add other logic in the branch?
The same goes with frameworks. I'll hear "that framework adds so much overhead." But if the overhead isn't visible to the end user and gives my developers the ability to generate stable code 4x faster, why wouldn't I use it?
That was a hard lesson to learn because I focused early on my career on being elegant, perfect, and "right." And I produced code that I could brag about and, guess what, a lot of people came along and struggled to maintain. I could get on a soapbox and call them "novices" or I could admit that I was programming for the wrong person: me, instead of the business.
Please, learn to be pragmatic.
Next Time We Will Do It The Right Way
Is the biggest lie we tell as a dev :(
That you can reduce your burnout by quitting. Maybe I should have quit sooner but I'm unsure if I would have appreciated the sabbatical as much...
The customer is all-ways right. Which means there is room to make the way, my own.
How a 1-hour job can wind up taking 6 hours....you all know what I'm talking about!
For me, it was time management and working with a team/communication. Until I started working with others, I kept to myself doing my own things. Once I started working with people, I had to adjust how I work, brush up on communication skills, and most importantly time management. This took a while, and I'm still not the best at it, but you need those skills in order to succeed as a dev. When you don't have those skills, you end up causing problems for everyone, and nobody likes that 🤔
"It's never about the code. It's always about the people".
To be honest, I'm still trying to learn this lesson. Most developers get sucked into the code, the language, the framework or the design so much that they actually ignore the people around them. Let me colour this with a few examples. Most developers talk about how productive they are in a particular language or framework. Instead, we should be looking at how productive was it to work with "this" team of developers. In another example, lots of developers even look for jobs that match a language that they know. Instead they should be looking for people they want to work with. The code figures itself out. Bad code is easy to change to good code within a few weeks/days. Bad teams don't become good teams in a few weeks/days. That takes years (if at all).
I'll re-iterate because I think this is important and needs to be said: "It's never about the code. It's always about the people"
I would say, trying to learn every single thing and thinking to become the best in all of those one day.
I was a simple fresher, simple because I was just a blank fresher with a decent logical sense and able to code in C language to a decent level and a bit of core java(not HTML, no javascript, no CSS etc because I hated UI/UX). However, I have started to learn java(java EE probably) for my project. I tried to learn everything that the brilliant architect of our project has designed. And I ended up learning everything in pieces. I have become so immersed in that that I ended up reading lot of time and trying stupid things and finally understood that I've take too much already. Take it one at a time. I became the goto for anyone even the seniors if they wanted to know of something. In the end, the project ended and all my knowledge was left with me with little use.
This time it was javascript. This time I was careful, I started doing little things. When I felt, I need something for doing it better, I started learning again. Slowly, the beast to learn everything was back and ended up reading almost everything on medium and even, the tc-39. I was initially a guy who was very much against UI/UX and at this stage I understood that it was just different and not a nightmare. Now, after almost 4 years being a professional developer, I understood that I need to understand how to solve a problem properly than learn a language.
However, it is important to apply language specific optimisations which could make your code faster. So, trying to learn too much is my problem.
I can say, j has a great point which I will be planning to do next time when I want to solve something but that next time is never coming though.
Cheers :)
The only thing constant is change
Today its technology x, tomorrow it will be y.
First - Learn how to learn
Discipline .... write/draw it first.
That one is still really hard. Because it feels like wasting time instead of shortening it. Although the result is almost everytime better and faster.
Still most of the time I just want to jump in the code.
I can't do everything.
I often start on one project, then quickly get sucked into another project because I've gotten bored of the first or want to learn something new. As a result, I have like 40 unfinished projects lying around in Github repos or folders on my computer.
I should clarify: I haven't learned this lesson yet, but I'm trying to. I'm trying to be a finisher of projects and not just a starter, so I can actually be a productive human being!
Wilferd Peterson calls successful people those with their heads in the clouds and their feet on the ground. I've got my head in the cloud... now I'm trying to reach my feet to the ground.
Letting others piss their own bed so they can learn from their failures.
An example of this is recognizing that new and shiny wasn't always better -- and quite often drags you BACK a decade or more as old failures had new names and sick buzzwords slapped on them.
See HTML 5 in terms of JUST being a markup specification, where everything people ooh-ing and aah-ing over have NOTHING to do with HTML -- they're CSS3 and ECMAScript. The only REAL advantages it gives you is a more compact contents for <head>... the new "structural" tags and nonsense like ARIA roles are pointless redundancies to what already existed in 4 Strict (H1..H6, HR, and general semantics), and they undid the attempts at improving accessibility (like letting TARGET into non-frameset documents) and not only created new redundancies (AUDIO, VIDEO are redundant to OBJECT), they greenlit old ones (EMBED). You'd almost think the WhatWG was so ignorant of semantics and the intent of HTML 4 Strict they were unqualified to make HTML 5's successor.
But RECOGNIZING that when everyone is singing praises from the rooftops is a bit of a fight even in your own head.
Same goes for a LOT of the new shiny ECMAScript stuff. A lot of it like some of the new functions are welcome, but you look at the Math object and they added functions for people too lazy to type "1 -" for trig? REALLY? Worse many of the language constructs -- arrow functions, spreads, etc -- just take the already cryptic C syntax and make it even harder to follow.
But RECOGNIZING that when everyone is singing praises from the rooftops is a bit of a fight even in your own head.
Other concepts like "OOP for everything", "functional programming" which is just functions for EVERYTHING no matter how minor, "composition" over "inheritance" all reek of the old joke about how if you have a hammer, everything looks like a nail -- or WORSE just sound like outright gibberish.
But RECOGNIZING that when everyone is singing praises from the rooftops is a bit of a fight even in your own head.
Or how most frameworks actually create more work, less sustainable work, and are in no way, shape, or form any "easier" or "make you more productive". More often than not they violate good practices, are created by people unqualified to tell others how to do things,
But RECOGNIZING that when everyone is singing praises from the rooftops is a bit of a fight even in your own head.
More so when few others see it the way you do blindly parroting those praises no matter how many facts you shove in their face. Ends up feeling like dealing with creationists or cultists.
BUT that's the really hard part, letting others blindly believe their made up fairy tales and basically screw themselves asunder without unloading on them using every four letter word in existence. People NEED to fail so they can learn. The hard lesson is LETTING people fail.
Then knowing how to put up with the fact they are willing to blame everyone and everything EXCEPT the technologies they chose.
Ok, I admit it, I never learned those lessons. But I'm trying.
John Welty
There are no learning shortcuts. Frameworks can help when you already know how to roll your own. Frameworks first will only delay necessary foundational learning.
UI toolsets can help you when you already know how to roll your own but if you use them first, it will only delay necessary foundational learning.
Testing later when problems arise is too late.
Refactoring patterns have been established, learn them sooner than later.
If you don't know how something actually works under the hood, you will be limited in your ability to work with it and sooner or later it will bite you when your velocity falls off a cliff and you're stuck by the limitations imposed on you by something you decided to depend on as a time saver.