what it really takes to be a professional programmer

1.

(http://sploid.gizmodo.com/10-underrated-movies-

you-probably-missed-in-2014-1678155314)10 underrated movies you probably missed in 2014 (http://sploid.gizmodo.com/10-underrated-movies-you-probably-missed-in-2014-1678155314)

on Sploid (//sploid.gizmodo.com)

2.Is Taylor Swift Prepared to Ruin Leo DiCaprio's Babelicious Life? (http://defamer.gawker.com/is-taylor-swift-prepared-to-ruin-leo-dicaprios-babelici-1678204106)

on Defamer (//defamer.gawker.com)

3.Eight Gorgeously Redrawn Cartoon Characters (http://kotaku.com/eight-gorgeously-redrawn-cartoon-characters-1678197084)

on Kotaku (//kotaku.com)

(http://kinja.com)

What It Really Takes to Be a Professional Programmer http://lifehacker.com/what-it-really-takes-to-be-a-professional-progra...

1 de 13 08/01/2015 10:02 a. m.

(/)


2 de 13 08/01/2015 10:02 a. m.

There's a lot more to professional programming than writing code. From working with a team to solve

problems to version control, you won't make it to the major leagues without a toolkit of other critical skills.

We asked you, and some other professional developers, what those skills are, and here's what we learned.

With all the buzz about learning to code (http://lifehacker.com/tag/learn-to-code), it's easy to think that

knowing a programming language is all it takes to be a professional developer. However, like other jobs, it

takes more than one skill to really be great. We can't list everything that every programmer may need, but

here are some of the most important skills (besides coding) you should work on if you really want to be a

developer.

While some media sources portray programming as a loner's craft, the truth is that it really involves a lot of

communication and working with others. If you work for a company, you'll be part of a development team

and be expected to communicate and work well with others (http://lifehacker.com/how-not-to-be-

the-coworker-everyone-hates-1492443040).

(http://lifehacker.com/how-not-to-be-the-coworker-everyone-hates-1492443040)


3 de 13 08/01/2015 10:02 a. m.

However, Jeff Bargmann, developer of Lifehacker favorites Fences (http://www.stardock.com/products

/fences/) and Bins (http://www.oneupindustries.com/bins), stresses that knowing how to talk and write

clearly and convincingly is even important for the independent developer:

Nothing in school prepared me for the amount of written communication I'd have ahead. (We just

code, right?) In your professional careerif you'd like to move up one dayyou'll spend a ton of

time communicating clearly, concisely and convincinglythinking from the perspective of the

recipientover email to coworkers, managers, clients/partners and hopefully one day executives.

And since you're used to doing things twice as fast as others (we're crafty, right?) it's going to be

frustrating, because it's going to take you twice as long to get this right. And as an independent,

this skill is a make-it-or-break-itbut by necessity you'll learn the hard way as you go.

Jeff also has some tips for developing your communication skills:

To clear this hurdle in stride vs learning on the go, you'll want real world practice (Just like how

you got good at coding!). Publish some short articles, read emails aloud, face criticisms, and

moreover just create for yourself experience; just like you did with that pet coding project.

If you don't have the opportunity to develop with a team right now, consider some college communication,

speech, and writing classes to learn to do it the right way. Lynda offers a wealth of awesome communication

courses (http://www.lynda.com/Communication-training-tutorials/1714-0.html?category=beginner_337) if

you're learning outside of the classroom.

Everyone knows what it's like to have a frustratingly dumb coworker to deal with, but what if


4 de 13 08/01/2015 10:02 a. m.

Many developers say that understanding a programming language is only a minor part of coding. Problem-

solving is another important skill that rookie developers often lack. Compare software development to

putting a puzzle together: you need to figure out how to connect one piece of your program to another, and

it's not always easy. Reader Jsimon (http://jsimon.kinja.com/)explains:

I've met people who have complete command of an entire programming language, but couldn't

solve their way out of a paper bag. Best example was in college when working a team project. I

was asked to take a look at part of the code someone else was responsible for because they couldn't

get it to connect to the server socket. He never set a port. He'd been troubleshooting for a week.

Then there are people who can solve problems and just have no grasp of the language.

However, problem-solving is a difficult skill to learn. Practice is key here. Take on small projects

(http://lifehacker.com/5836753/how-to-take-your-first-coding-project-from-start-to-finish) like developing

note taking applications, calculators, or anything you find interest in. When you do this, focus on the logic

behind the code, and learning to think like a computer (http://lifehacker.com/dont-just-learn-to-code-

learn-how-to-think-from-comput-1598683903), rather than just understanding the language.

Learning how a computer works beforehand also helps. This tip comes from reader Jacobm001

(http://jm001.kinja.com/):

Problem solving is the biggest part of what we do. Computers are weird, and you usually need to

relearn how you think about problems. To be effective, you need to truly learn how a computer

operates and understand how the CPU processes information. I hate assembly personally, but I'm

incredibly thankful that I took a course that focused on it. Programmers who have at least a little

assembly under their belt have a much better idea on how to properly implement things.

Like Jsimon said, knowing how to both code and solve problems to connect the pieces is key. As you start to

develop real programs, focus on developing a systematic approach to solving the problems you'll face

(http://lifehacker.com/5836753/how-to-take-your-first-coding-project-from-start-to-finish)

You've learned to code, but now what? You may have some basic skills, but you're not sure


5 de 13 08/01/2015 10:02 a. m.

(http://lifehacker.com/5795228/how-to-solve-just-about-any-problem).

If in college, you'll soon start working with teams in your programming classes to develop projects.

WindowsSVN and GitHub are two examples of tools development teams use to work together to create and

update open source applications. These are available to everyone, but companies use Subversion and Apache

SVN, among others. You should go into a new job understanding the basics of how these systems work so

you can hit the ground running with your new teammates. It takes some time and practice to learn, so you'll

feel behind if you land a job without knowing how to use at least one of them. Luckily we've already broken

down the steps for using GitHub (http://lifehacker.com/5983680/how-the-heck-do-i-use-github), and even

showed you a cheat sheet to help you master it (http://lifehacker.com/master-github-shortcuts-

and-commands-with-this-cheat-sh-1572300741).

(http://lifehacker.com/5795228/how-to-solve-just-about-any-problem)

Problems can be difficult to solve when we only know the issue and none of the steps to fix it.

(http://lifehacker.com/5983680/how-the-heck-do-i-use-github)


6 de 13 08/01/2015 10:02 a. m.

The only way you'll truly master the system is practice. If you're in college, the time will come for you to work

on a fairly large team-oriented project in class. When it does, ask permission to use GitHub or a repository of

the sort even if the instructor doesn't require it. Find a team to work with if you're learning on your own,

either by joining a project that's already on GitHub or by finding a group of people (http://lifehacker.com

/use-meetup-to-start-a-networking-group-even-if-youre-u-1602301263) you want to work with and starting

a new one.

Technology is always evolving, and with it, so should a developer's knowledge base. If you want to stay

relevant in your field (http://lifehacker.com/hold-on-to-your-inner-student-to-stay-relevant-in-your-

1627907796), it's important to keep up with new and updated programming languages, software, and

Dear Lifehacker, I've learned to code and want to start using GitHub to manage my projects.

(http://lifehacker.com/use-meetup-to-start-a-networking-group-even-if-youre-u-1602301263)

Just because you don't have a job, or don't have a job in your field of interest,


7 de 13 08/01/2015 10:02 a. m.

hardware. Reader Wakers01 (http://wakers01.kinja.com/) explains:

. . .you will be learning new languages, technologies, and tools with a frequency that would allow

you to phase shift. You must be willing to examine new tech, analyze its merits and pitfalls, and

assimilate it rapidly. Notice I said "assimilate" and not "learn". I mean you must fully absorb,

understand, and integrate this new thing into your skill set, not just acquire some new knowledge

about how thing x works. It's not just software languages and tools either, you will also be learning

how businesses operate and how business users do work within that business. As long as you can

maintain an excitement for learning new things, you will be fine.

There are a lot of things you can do to make it easier to learn new skills quickly. For example: you'll use your

memory more efficiently if you take the time to understand exactly how it works first (http://lifehacker.com

/how-your-memory-works-and-three-ways-to-improve-it-1370487727). Learning also involves

comprehension, so in addition to the communication tips we gave you earlier, focus on boosting your

reading comprehension (http://lifehacker.com/5872944/how-to-boost-your-reading-comprehension-

by-reading-smarter-and-more-conscientiously) so you can get through tech documentation and other

written resources with relative ease. Understand that you won't be able to memorize everything, so having a

good note taking system (http://lifehacker.com/5989980/ive-been-using-evernote-all-wrong-heres-

why-its-actually-amazing) and creating idea indexes for paper books (http://lifehacker.com/get-more-

out-of-the-books-you-read-with-an-idea-index-1650296391) are good ways to stay organized and quickly

find information you need to reference.

(http://lifehacker.com/hold-on-to-your-inner-student-to-stay-relevant-in-your-1627907796)

There are benefits of presenting yourself as an expert. Confidence in your knowledge affords

you

(http://lifehacker.com/how-your-memory-works-and-three-ways-to-improve-it-1370487727)


8 de 13 08/01/2015 10:02 a. m.

Start with the basics: view learning as a skill that you should focus on mastering. Once you do, you'll have an

easier time rolling with the punches of technology, and staying ahead of the competition in your field.

There's a lot more to programming than just sitting at a desk and writing code. If you understand that early,

you'll have a much better opportunity to gain more critical skills that employers and clients need you to

have.

Photos by Allan Ajifo (https://www.flickr.com/photos/125992663@N02/14599057004), Sebastiaan ter Burg

(https://www.flickr.com/photos/ter-burg/8812569383), Liza (https://www.flickr.com/photos/lizadaly

/2944376209), Lachlan Hardy (https://www.flickr.com/photos/lachlanhardy/2360329845).

How would you like to be able to recall the name of a client or associate you just met? How

would

Best lesson I learned - nothing is set in stone and accept change.

No matter how much time you spend on scope, requirements, discussions, (you name it), the minute it

hits production floor it will change. People do no know what they know till they see and play with it -

this is a nature of the beast. Just accept it.

As a programmer, the most valuable skill I have is my ability to consume documentation. At any given

moment in time I can't know everything I need to know to solve a complex problem, so I don't waste

my time trying to remember as much of it as I can. Instead, I remember WHERE the information is. I

don't need to know how to implement a complex algorithm from memory, but I do need to know that a

particular algorithm exists, and where to rediscover it.

Also, a healthy dose of pessimism is a great attribute for a programmer looking to write robust code.

I've encountered way too many programmers who think the world is a magical place where the client

always does it right and the server never fails to do its job properly. These programmers are constantly

plagued with "impossible" bugs as they are faced with malicious clients who purposefully break the

523LikeLike


9 de 13 08/01/2015 10:02 a. m.

software and faulty hardware that needs replaced.

In my experience, from teaching courses at the college level, working in industry on teams others and

working as a consultant (which includes jobs where I sometimes help companies find out why their

code doesn't run in a timely manner), the biggest difference between a "programmer" and a

"professional programmer" is one of them "writes" code and the other one "knows" code. Anybody can

go online, look at documentation for a programming language, and get a few simple programs running

in a few days. But there is really minimal understanding for what the programming language is doing.

For example, one of the companies I worked with had code written in Java. They hired somebody who

learned how to program on their own, from documentation and examples they found on the Internet.

Turns out, he just took syntax he found in an example, and was having issues with passing variables to

a function by value vs. passing variables to a function by reference. He thought he was passing by

value, but it was going by reference, so the code was changing the original data, which then broke

everything else that used it after that function call.

I think the other issue that goes with knowing code vs. writing code is really understanding what's

going on underneath to understand how to optimize code. As most people learn to program, they don't

really do "large scale" programs where optimization really makes a difference. If you're running small

programs, you're not going to notice if it takes 1.97 seconds or 1.84 seconds to execute, so writing

sloppy code really isn't going to make much of a difference. But, write a program that is going to be

used hundreds, maybe thousands of times per day with a much larger scale of operations, and now, a

runtime of even 5 seconds and a run time of 4 seconds is going to be a much more noticeable

difference that adds up.

So, to add, I'd say understanding what's really happening underneath as the system executes code is

very important.

May I also add: Be creative! If you're a developer who consistently pushes out creative ideas, and youwere trying to show your boss why he should hire you rather than Person B, then you'd have the upper

hand, even if Person B is a better programmer and knows more languages. Furthermore, if you were

doing development by yourself and you push out more creative ideas than the next guy, chances are,

you'd be more successful, because one of the ideas you'll have will end up topping the App Store

charts. You'd also have more apps out there with more features, causing you to make more money.


10 de 13 08/01/2015 10:02 a. m.

I would also add: Be adaptable to different environments. As a programmer, I often walk into projects

that are already built. In most of these cases, my job is to add features or fix bugs, not to rebuild the

entire system. I have to be able to work within an existing architecture or framework, even if it doesn't

make sense.

There is no magic way to learn programming. It takes years to master debugging, modifying other

peoples code, writing code that people behind you can follow and most certainly takes years to

understand a language and its frameworks fully. Nobody can teach you how to be a good programmer

it is a learned skill through self practice. I would also add some people simply do not make good

programmers.

FYI when a programmer starts slinging buzz words, talking about how great some rapid development

system is or how many languages they can code in, walk away. In fact run as fast as you can because

that person is a relative idiot that couldn't code his way out of a buggy hello world app.

The best lesson I can pass on is that a language is a tool to get a job done. Pick the right tool but focus

on the job. Developers often focus on expanding their resume by writing in the latest and greatest

rather than solving the program using the tools they have mastered. It is very important to learn new

skills but do so on throw away projects. Do not cut your teeth or use unproven systems on mission

critical applications but do make time for fun learning projects.

I'd add: Be open to criticism and self-criticism.

We usually love OUR code. If it works, we usually think of it a beautiful and perfect. It's not hard to

become a "know it all". Re-evaluate your solutions from time to time looking for chance of

improvement. Think of your code as a living thing.

Be humble. Your code can ALWAYS be better. If you work alone, this could be hard to see, but if you

work in a team (as you should ideally do), chances are than "the team" can do a much better job

solving problems that you on your own.

Expose your solutions/ideas to scrutiny. Be open to accept suggestions and act accordingly.

This is an awesome addition. Thanks!


11 de 13 08/01/2015 10:02 a. m.

Always assume that the code you are writing now, you will personally find offensive 2-3 years down

the road and wonder how you could write such crap.

If you don't, you're not learning/improving... and then 20 years from now, some jr dev is going to look

at you code and wonder why they have to maintain you're code that's full of anti-patterns, thread leaks,

or other things that you should have known better that to put into production in the first place.

I like this.

I would add that you need to learn to consider as many different scenarios as you can. Users and

developers don't always think the same way, so you may find that your clients are doing something you

never expected. Also, consider edge cases and unusual circumstances. Finally, don't sweep security

issues under the rug or try to address them at the end. Plan for it right from the start.

I would also add that you should read other people's code and see how it works. As a general rule, you

spend more time reading code than writing it, and it's frequently not your own code that you're

reading. I wish I had read more code in the past (open source projects, for example.)

Regarding school, I highly recommend that you always ALWAYS use source control. Get a BitBucket

account (or GitHub, but you get fewer private repositories) and use it for every programming project,

even personal projects. You will gain familiarity with source control, and you'll always have your code

available on any computer. You'll never lose it in a freak computer accident. If you ever need to

provide documentation of a project's history (e.g. you have a useless teammate or you're accused of

academic dishonesty), you have a full history of all commits. There is really no down side.

Awesome advice. Thanks! It's so true that users and developers don't think the same. If you're working

on a personal project, release a beta (even if it's just to your close friends) and ask them to tell you

what they don't like about it. They'll often find issues you wouldn't even think to look for.


12 de 13 08/01/2015 10:02 a. m.

On communication: as important as speaking/writing/expressing yourself is, reading/listening is

more important. Universally, I think, but here as well. Users will say 'I want this.' You learn to get clear

about what leaps to mind when you hear 'this,' and all the blanks your mind fills in/doesn't fill in, and

you learn to draw out the details of what they want and how it differs from what you imagine.

Agile development processes are designed around making coding part of that process'so we built

this... is this going in the right direction?' 'Yes, but...' It's conversational, or 'iterative,' as we like to say.

I'm not that experienced with agile stuff, but generally I like the ideas in it.

So true! When people think of communication their minds often go straight to what they want to

communicate, rather than what they should be taking in.

Also, don't test your code to prove that it works... test it to prove that it doesn't.

Always go into unit testing knowing that there is a bug and that you have to find it before you release. I

always feel funny if release code that I did not find a bug in as I feel that I missed it and it will come

back to haunt me. Of course that could be because I'm not very good ;)

This is a good rule of thumb. You should actively look for bugs and kinks when you test.


13 de 13 08/01/2015 10:02 a. m.

what it really takes to be a professional programmer

Documents

professional programmer

code http

bins http

professional programming

professional developers

sploid sploid

professional careerif

important skills