Details
-
AboutWeb dev.
-
SkillsJs, css, sass, rails, html, C#, Java, Ruby, C++, c..
-
LocationSweden
Joined devRant on 4/2/2016
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
-
As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.
I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.
These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.
Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.
All I want to say is:
No time was lost.
This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.
Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.
One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.
You don't notice the things you take back from your failures, they slip back sticking to you, undetected.
You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.
You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.
You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.
Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.
Please, for the love of code...
Start and fail as many projects as you can.30 -
!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!221 -
Give a man a program, frustrate him for a day. Teach a man how to program, frustrate him for a lifetime1
-
Love devRant! Where can I donate to help keep the Devs supplied with adequate redbull and dorritoes?6
-
Boss to client on phone: 'We'll get something to you around the middle of the week'
Boss to me (noticing my panicked look): 'Late Thursday or early Friday is the middle of the week if you count the weekend'3 -
CEO emailing on a Saturday evening to suggest a "demo" at the end of the sprint. There is a demo at the end of EVERY sprint and always has been. Don't pretend to "work" on Saturday - you are fooling nobody.8
-
When you forget your password, go to change it and get greeted with:
"Your new password cannot be the same as your current password!"1 -
Clients that barely can turn on their computer that have opinions on how much complexity and time is involved developing X feature. I'm no rage-o-holic, but that is one of those rare things that make me want to stab someone in the face.
-
The headset rule. If put on, project managers, the pope and everyone should stay away the developers. If put on one ear, it is allowed to disturb if it's important. Headset off, party time.3
-
Send over the entire directory for a WordPress site we completely overhauled with new plugins, custom theme, redid content with visual composer, etc. I tell him to backup his site and then put everything I give you as fresh. He tells me he can't just wipe out his entire site that's unacceptable. I ask him what's the problem? he rambles on and says a lot of words that don't really mean anything then says security. so I call him out on it, what security issues do you have? well we have users and permissions setup he says. I explain That I copied his users table over when we did the redesign, so it's the exact same stuff. so I say again, why can't we just replace everything? well that's just not acceptable he says. I ask him again, what EXACTLY is your problem with replacing the site since I already addressed your security concern. he couldn't answer me so now we have another conference call tomorrow morning with more people from their team. I'll let you know how it goes.
tldr; clients are idiots, call them out for the dumb shit they say and have no response.7 -
Fairly new here. Saw the ad for this on instagram and thought it was the coolest idea ever. Thanks guys for making this app :) now I can rant about how awful my PM is.2
-
Congrats to localhost for being the second devRant user ever to reach 1,000 points! I've greatly enjoyed his awesome posts and I know a ton of other people have too! Thanks for the laughs/great convo and I'm looking forward to an NYC meetup in May :)4