Details
-
Locationlocalhost
-
Github
Joined devRant on 4/23/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 your teacher says he prefers this:
class A
{
// code
};
over this:
class A {
// code
};
me: can u not26 -
!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 -
We're excited to announce the first devRant-sponsored hackathon! It features everything we could have dreamed of in a hackathon: huge prizes ($10k to first place and others), an awesome beer-themed dev competition from lead sponsor Anheuser-Busch, lots of free beer, and an awesome setting at Alley in Chelsea NYC (devRant's hometown, we'll be there!)
It's taking place right here in NYC from March 25-26 and @trogus and I will be there and we really hope we can hang out with members of the devRant community who are participating. devRant is an official partner of the hackathon and we're very excited about the competition itself. There are two challenges teams can pick from: "Internet of Things" (Raspberry Pi’s, Arduinos, etc.) and "Data Insights" - both with the goal of finding creative solutions/innovations to help people drink more beer!
Tim and I look forward to hopefully seeing many of you there. Full details and registration here: https://hacktheworld.beer/NYCHackat...
Please let us know if you have any questions and let's hack some beer!
P.S. the hackathon is 21 years and older only because of the beer theme46 -
How to properly have fun on a Saturday night:
1. Suddenly become deeply unsatisfied with current linux distro
2. Evaluate alternatives
3. Decide some change is needed but not too much: install fresh version of old distro
4. Once again, experience profound dissatisfaction
5. Opt for radical change
6. Erase all linux partitions, form a super partition and install a new linux distro on it
7. Spend hours familiarising with the new distro
8. Spend more hours googling stuff and typing commands in the terminal
9. Download current devRant avatar, send it to the PC via Telegram and set it as user's avatar for the welcome screen
10. Feel deeply satisfied
11. Accidentally wake girlfriend up while trying to get to bed. Get told off for staying up until 4am and for "being such a nerd"21 -
Pleb: "What's your job?"
Me: "I'm a programmer."
Pleb: "Great, because I have a problem with my pri..."
Me: "STOP! Last person who thought I was a printer support serf got strangled with the printer cable."
Pleb: "But it's a wireless printer."
Me: "Right, where's the power cord?"5 -
Let's clarify:
* Github is not Git
* Android is not Java
* Unit test is not TDD
* Java is not OOP
* Docker is not Devops
* Jenkins is not CI
* Agile is not institutionalised total chaos
* Developer is not Printer Support52 -
Interviewer: Oh ...we don't really use version control here..it's too hard to get the different offices on the same page.
Me: ...6