"The Best Programming Advice I Ever Got" with Lauren Darcey
Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers here.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Name:
Lauren Darcey
Job Experience:
Lauren Darcey is responsible for the technical leadership and direction of a small software company specializing in mobile technologies, including Android, iPhone, Blackberry, Palm Pre, BREW, and J2ME and consulting services. With more than two decades of experience in professional software production, Lauren is a recognized authority in enterprise architecture and the development of commercial-grade mobile applications. She has written extensively about mobile application development, especially Android, with her co-author, Shane Conder. Some of their books include: Sams Teach Yourself Android Application Development in 24 Hours, Learning Android Application Programming for the Kindle Fire, and Android Wireless Application Development Volume I and Volume II.
Most Frequently Used Programming Language:
These days, probably Java, as I do a lot of Android app development.
Advice:
Perhaps the piece of advice that has saved me the most time, effort and headaches is: Don't re-invent the wheel without good cause.
There's an arrogance to programmers, especially newly minted ones at their first job. For some reason, perhaps it's ego or just naïveté, we all seem to go through a phase in our careers when we decide to design—on-the-fly—a better solution to a well-known computer problem. We think that we can just conjure up some improved version of some programming construct or database mechanism, without rigorously testing our idea. Even worse, once we've implemented this little gem, we honestly believe that we have done our team a favor. This habit is especially dangerous close to an app release deadline, when we might mistakenly call it "performance tuning."
Here's an example. I've seen countless junior programmers try to write their own sorting or searching routines from scratch. For some reason these developers seem to think they can come up with some new approach that's going to magically beat out the handful of sorting and searching algorithms whose well-defined benefits and drawbacks have been studied for decades. I've seen this particular issue happen pretty regularly when otherwise clever hackers (without a formal computer science background) join a traditional development team.
In this day and age when development schedules are tight, apps often ship in beta, and users expect bug fixes overnight or your app ratings tank... the more custom code you include in your apps, the less agile your team is going to be. Squirrelly code like untested, made-up-by-the-seat-of-your-pants algorithms do your development team and your users a great disservice. You want your code to be compact, bug-free, scalable, and easy to maintain and understand. Maybe hard-to-grok code is job security to some. If you want to be stuck maintaining the mess you wrote for the rest of your days, well then great work. But my idea of job growth is: Write it clean, be proud of it, hand it off to someone who can maintain it without needing to ask you countless questions about it, and then move on to the next interesting project.
So unless you have a really good reason, use standard, well-understood components in your code. Avoid custom algorithms, especially when you're just beginning to develop a product. You can always refine and replace these areas later when your application begins to test the limits of standard solutions. Innovate where it's most important to your product, and do so carefully and deliberately, not willy-nilly or just because you can. At some point in your career, you may have the opportunity and privilege to invent something new or advance technology, but unless you're on a research team, those opportunities are going to be exceedingly rare and special. You'll recognize the right opportunity when part of your deliverable is a research paper in 12-18 months, not a build to the testing team the next morning.