Details
-
AboutFront-end developer
-
SkillsJavaScript, PHP, Python, Node.js
Joined devRant on 4/19/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
-
When you start a new job as a Senior Developer, and start asking questions about the code, and you have these collections of conversations with other front-end people:
Exhibit 1:
Me: Ahh so I see the filtering and pagination is all done with Javascript in the front end...
Random dev: No, it's done with Angular.
Exhibit 2:
Me: I think we should add frontend pagination to this page. There will be too many elements on it if you're a customer with 2000 servers.
Random dev: Don't bother, there's no pagination in the API call... So that will not gain any performance.
Me: But it wouldn't take long to implement and it would improve the user experience, why would you want to show ALL the elements, when you have an option not to... Also, it WILL be a major performance hit, especially on mobile.
Random dev: People will use search anyway.
😥🔪
Also, there are no coding standards, every file looks different, and my opinion is being disregarded in everything, and I thought my last job was bad...
Seriously how are some people hired as front-enders?
Since I just took this job, I feel obligated to stay a couple of months... But hey, don't cry for me, I might have more rants for you. 😂
Sorry for the long rant, here's cake: 🍰5 -
Then there's that awkward moment when variable "count" doesn't work because I called it "cunt" later on.6
-
No, you self-centered asshat,
the HTTP RFC is not just a set of pedantic suggestions.
Fix your non-standard shit. -
!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 -
Got a job with EA
Went down like this during the interview
Hiring Manager: your second part of your resume seems to be missing?
Me: second part is $20
Hiring Manager: Welcome on board9 -
How I've decided to answer the "can you hack" question from here on in...
"Can you show me how to hack this account please?"
"Sure, you'll need a hammer, a blow torch, chloroform, some pliers and couple of bottles of really pure vodka!"
"What the hell?!"
"Oh, it's so much quicker to just extract a password from a person, than it is to break into a system, I'm not exactly trained in inflicting pain on the human body, but I'm sure you'll be able to figure it out through trial and error, good luck!"15 -
0. Plan before you code. Document everything. You won't remember either your idea or those clever implementations next week (or next month, or next year...).
1. Don't hack your way through, unless that's what you intend to do. Name your variables, functions etc. neatly: autocomplete exists!
Protip: Sometimes you want to check a quick language feature or a piece of code from one of your modules. Resist the urge to quickly hack in the test into your actual project. Maintain a separate file where you can quickly type in and check what you're looking for without hacking on your project (For example, in Python, you can open a new terminal or IDLE window for those quick tests).
2. Keep a quiet environment where you can focus. Recommend listening to something while coding (my latest fad is on asoftmurmur.com). Don't let anything distract you and throw your contextual awareness out of whack.
3. Rubber ducks work. Really. Talking out a complex piece of logic, or that regex or SQL query aids your mind greatly in grasping the concept and clearing the idea. Bounce off code and ideas with a friend or colleague to catch errors and oversights faster. Read more here: https://en.wikipedia.org/wiki/...
4. Since everyone else is saying this (and because it merits saying), USE VERSION CONTROL. Singular most important thing to software development aside from planning and documenting.
5. Remember to flout all of the above once in a while and just make a mess of a project where you have fun throwing everything around all over the place. You'll make mistakes that you never thought were possible by someone of your caliber :) That's how you learn.
Have fun, keep learning!3 -
Today's my lucky day for job rejections...
"Unfortunately we have decided not to proceed with you as a candidate because the salary range you expect lies outside our budget."
That's very interesting indeed because in the very first interview (phone call) you asked me about that range and I gave it, straight and simple.
Then I had to do a coding challenge, which I usually refuse, but did anyway. It took about 15 hours. Let's not forget that it had nothing to do with the job I was applying for, but OK.
After that, a second interview, which took 1.5 hours and a third, which gobbled up 2 hours of my time.
Then you tell me that you're not willing to fork over the dosh, after having wasted 18.5 hours of my time!
Thank you very much, you anus blossoms!9 -
Reinventing the wheel can be very valuable. Even if you don't create a better wheel, you'll learn a lot about how it works, which can really help you out in the long term.16