I would love to read this article but I literally can not read it with the colors and fonts chosen.
Why You’re Failing to Realize Your Potential as a Developer
11–20 of 28 posts
Re: Why You’re Failing to Realize Your Potential as a Developer
#12"dude, stop Gandalfing the documentation and start coding something,"
You are a startup with documentation? Am I the only one that finds that funny?
Re: Why You’re Failing to Realize Your Potential as a Developer
#13Average developers are those who aren't committed to getting better or keeping up. In some software areas, those two terms are synonymous.
To use a specific example, in the mobile development world, which is arguably one of the "hottest" development jobs (the dot-com-like hype gold rush aside), you have to keep improving to continue to be relevant, let alone 'realize your potential'.
The above average mobile developer keeps up with the best-in-class practices and the ability to deliver to the baseline customer experience expectations for the platform (which keep going up and up - customers are spoiled by the Instagram/Airbnb-type apps of the world).
For example, iOS has gone through significant changes from iOS 2 (original) to iOS 6. Maybe three or even two years ago, using ASIHttpRequest was good enough for async network operations. Now, everything has gone to blocks. Sometimes enough blocks tied/nested together to put Lego to shame. Storyboards have started to replace tedious UIViewController plumbing. Modal dialogs used to be tolerated by customers, now obvious use of them make your app look cheap and outdated. Custom animations (and yes maybe even custom tab bars) are almost expected (this is good and bad) - but simple stuff like tapping on an image to expand it to full-screen and tapping on it to collapse it back to thumbnail - the customer expects that.
As for Android, Android is running at a pace that leaves average developers behind. Someone who still uses TabActivity for apps is rightfully categorized as out-of-touch with the post-Holo look and feel. If you don't have an ActionBar in your app, your app is out of date. Someone who uses BroadcastReceivers for piping data between Activities and Services is out-of-date (see Square's Otto or GreenRobot's EventBus).
I know this devolved into a bit of a rant - but developers have to keep up with the best-in-class practices - and in the best case - "rockstar" class developers like Jake Wharton of Square for Android - can inspire others and give the community the right tools to push the entire platform forward and make it more competitive (in this case, with iOS).
I believe the best developers share their knowledge (whether in a closed environment like a team - or best - Github and conferences and podcasts/screencasts) so that others can become better.
Re: Why You’re Failing to Realize Your Potential as a Developer
#14If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." Otherwise please use the original title, unless it is misleading or linkbait http://ycombinator.com/newsguidelines.html Please
I've never understood that rule, seems kind of arbitrary...
Re: Why You’re Failing to Realize Your Potential as a Developer
#15I agree with most of these, excapt for the one that goes, "Strong developers accept that the business costs in a rewrite are usually unacceptable and should be avoided". What if the existing codebase is a rats-nest of complexity? WHat if the previous team were "bad developers" and they wrote code that was neck-high with technical debt? I think great developers are lazy, and not wanting to wade through a bad codebase is a trait of a good developer.
Re: Why You’re Failing to Realize Your Potential as a Developer
#16If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." Otherwise please use the original title, unless it is misleading or linkbait http://ycombinator.com/newsguidelines.html Please
I've never understood that rule, seems kind of arbitrary...
The number is arbitrary, but advertised as though it were not.
Re: Why You’re Failing to Realize Your Potential as a Developer
#17All of them are traits of junior developers. (I know, because I was one at some point). With enough experience, and working in different type of problems they will start disappearing bit by bit. You will have both those skills, and the confidence to tackle major problems.
What's needed to reach that point:
1. Work on different type of projects and features (i.e. both back end, and front end). Being full stack is better early in the career.
2. Work on your own project end to end. It gives you a complete different perspective and grows you as an engiener by leaps and abounds(you are the PM, engineer, QA, and consumer advocate).
3. Learn really well (be fluent) at both language types. One static (Java, Scala, C++, C, Objective-C), one dynamic (Javascript, Lua, Python, or Ruby).
4. Work with a super solid/10x-er engineer, the multiplier type. You will learn a lot by working with somebody that is both good and has a lot of experience.
Re: Why You’re Failing to Realize Your Potential as a Developer
#18I think the author was talking more about rockstar/genius developers with many years under their belt than simple "good" or even "great" developers.
I also think the author fails to realise that a lot of what he recommends isn't easy to come by.
Don't get me wrong, it all makes a lot of sense; every word. However I agree more with antoko in that perhaps the focus sometimes needs to be on increasing developer confidence. After all, we can't all be rockstars can we?
Re: Why You’re Failing to Realize Your Potential as a Developer
#19If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." Otherwise please use the original title, unless it is misleading or linkbait http://ycombinator.com/newsguidelines.html Please
Interesting. I think I agree with @freework, although it's quite trivial I suppose.
There are 10 items in the article, 10 separate points with headings. The author chose to draw attention to that in the title, maybe to offer a clue as to the quantity and arrangement of the document?
Re: Why You’re Failing to Realize Your Potential as a Developer
#20It's not bad advice - and also nothing new - but it's very condescending: "I want to help average developers who want to improve by calling out 10 performance-killing behaviors that stagnate the careers of most developers". What makes this guy so great? He states that his product is "difficult even for large companies to master" so I'm inclined to think he's doing a few things wrong himself.
He paints a black and white picture and divides everyone into "average" or "good", that's my only issue.
In reality, each project demands different solution, some have heavy UX challenges, others strictly an architecture puzzle. There's bound to be variation in how "good" our work is for each aspect of the project. In one year, most of us have done lots of stuff, some really good, other stuff good. Like making an album, not every song will be a classic, but you'll break even and be home before midnight most nights.
Sometimes the solution is not pretty.
There's also developer ability in the mix too, and developer-philosophy! With javascript, for example, sometimes your function might be "the long way around" but still fine. Ok so it could have been done a little more efficiently if you'd constructed that other array and took that extra step etc etc. But here's the thing: in some languages such as javascript, taking the long way around might afford you better readability of your own code later, or just easier to work with for adding new elements later. It's YOU who makes that call. Sure, there's advice to be shared and we're all learning, but there's also a flexibility with programming that affords all but the most critical applications a bit of breathing room. If someone sees a better way to write a function, then great, update it if you feel it's a good choice. Or tell them they can update it anytime.