Ask HN: Are top developers just guessing?

[sneakpeek]

Ask HN: I graduated with my undergraduate CS degree about a year ago and landed a job with a mid-sized company that provides engineering services. While attending school I came to believe that top developers are people interested in learning everything they can about development - and I liked the idea of working with such people. However, the reality that I've experienced is that the developers most willing to guess about how code works, copy and paste googled code, and push others to feed them answers instead of doing research on their own are considered to be the top developers because they 'get things done'. Has anyone else experienced this? If I want to succeed, do I need to stop caring about solving problems and start caring about getting as many lines of code out the door as I can? Is it like this everywhere? I've hit some real lows during the last year because of this attitude so any feedback is be appreciated.

[ComputerGuru]

It sounds like you're posting here in hopes that someone will affirm your suspicions and tell you that top devs are just luckier or play looser with the rules and overstate what they can do.

I'm not sure whom you've seen that you're referring to, but the top devs that I know are nothing like what you describe. To me, the defining characteristic of a top dev (though I will not go off on a tirade here, and so I will keep this short and sweet) is that they understand the systems they are building on and the problems that they are trying to solve.

Being a developer is NOT about the code, it's about how you come up with what you come up with and the strategy and approach you take to solve a problem. Computer Science is about algorithms, but software development is about coming up with solutions to the problems presented. You can't solve a problem - no matter how well you can "code" - if you don't understand the problem. And the better you understand the problem, the better of a solution you'll be able to come up with.

I've seen top devs that copy and paste code from StackOverflow and they get the accolades and the resounding praise. And they earned every bit of it. Why? Because it's not about the code snippet they copied from SO to convert a byte array to hex representation or to neatly serialize an object and transmit it, encrypted, over the wire to a remote server. It's about knowing what the code should do in the first place.

It's not about lines of code, it's about what that code does. A CS degree does not teach you to engineer software, it teaches you to write algorithms.

[sz4kerto]

> they 'get things done

Yes, that's the trick.

> guess about how code works

That's not a bad thing per se. Time spent vs. accuracy is a compromise. You need to figure out what is the optimal depth of understanding you need to achieve to get the task done.

> copy and paste googled code

Sure, funderstanding code is usually much easier than writing it, so if you find something on SO that does exactly what you need then yes, just paste it.

> If I want to succeed, do I need to stop caring about solving problems and start caring about getting as many lines of code out the door as I can?

No, not at all. You should care about solving problems, but the problems you're trying to solve should more or less overlap with your employer's problems. If you are developing a trading system where the expected throughput is 10 trades/sec, then designing something that can cope with 1000 trades/sec might be interesting but it is not your job. If you need to fix some bug in 20 minutes because many things (money, reputation, etc.) depend on it, then yes, it might be just fine to guess, hack together something and fix it later properly instead of spending a couple of days on the 'correct' solution meanwhile the company is collapsing around you.

In short: what you do is part of a larger context, you need to align your priorities with that.

[ajankovic]

> In short: what you do is part of a larger context, you need to align your priorities with that.

Let me just point out that this is the hardest part of being the professional. Reasons for this are many. One example is that larger context can be obscure to you due to bad company organization/management.

[nkvoll]

> if you find something on SO that does exactly what you need then yes, just paste it.

I think you should be very careful about doing this without an explicitly stated license with reasonable proof of author copyright for the code snippet. It's one of the things that can easily compromise the legal security of a codebase.

[chrismcb]

No, please no. Just because it is on SO and it appears to do what you need, doesn't mean it does what you need, or does everything you need, or is production quality. You should make sure you understand what the code is doing. Only then will you know if it solves your problem and solves the edge cases. You are right in that you need to balance a hack versus a proper fix. But always aim for the proper fix first.

[u04f061]

Can't disagree with any of the point.

[clavalle]

The word you're looking for is 'resourceful' and, yes, the top developers are resourceful.

No one knows everything. Not even close. If that is what you are looking for, some Godlike mastery of the esoteric, you are in the wrong field.

If you are willing to be resourceful which means dealing with the inherently messy business of solving Real Problems blinds and dead ends the occasional short cut and all, well, welcome! This is chaotic, but we love it!

Writing beautiful code is important mostly because, in the long run, it saves time and effort. But the perfect is often the enemy of the good. All of the beautiful code in the world is worth nothing if it doesn't solve somebody's problem and, usually, sooner is far better than later. If that bothers you, there is always academia.

What separates the masters from the cut-and-paste programmers churning out garbage is knowing when it is ok to take shortcuts and when it pays to take due care.

[m0g]

academia is extremely prototype oriented so it might even be worse than industry in this regard, fyi.

[joe563323]

> No one knows everything. Not even close. If that is what you are looking for, some Godlike mastery of the esoteric, you are in the wrong field.

       What about Don Knuth who wrote TEX for a decade ?

[ajarmst]

It sounds like you only have a sample set of developers at one company, perhaps being evaluated through the lens of some personal bitterness. It's possible that you may be simply experiencing a case of an organization that uses bad metrics to reward developers: measuring productivity by LoC is basically an industry joke, but still occurs. Other nearly-as-bad metrics like "tickets closed" are common. It may also be a cultural thing at your particular organization, or a reflection on the particular task. What's the use for this code? What is its expected time-in-service? Is this experimental or production code? Is this boilerplate code for an uninteresting problem long solved? Sometimes a mark of a good developer is to know what to spend valuable time on and what not to (as in the problem of premature optimization.) Finally, it's not necessarily a bad habit to ask someone you know has the answer rather than research it yourself, especially if the problem is unimportant/uninteresting/not your area of expertise.

[sippndipp]

There is some truth in there... Too many cargo cult devs out there: http://en.wikipedia.org/wiki/Cargo_cult_programming

But to answer your question: It depends on the business you're in and the dev culture your company established.

In the most consulting shops or early stage startups I've seen the situation that you're describing. Cranking out code because visible features / products is the only thing a customer cares about.

But in companies that build a sustainable product that needs to scale things are different. They embrace good architecture TDD/BDD. They embrace time for refactoring. Maybe you should switch your job :-)

[thaumaturgy]

You're asking a community full of people who consider themselves to be "top" developers whether there's room for criticism of top developers. Even if your observations were right (and I have no idea if they are or not), that's not likely to be a very productive conversation.

Don't focus so much on competing with other people. If you want to succeed, then keep improving your own skills and approach. It doesn't necessarily need to be the same skills and approach as other people, it just needs to work for you. If taking the time to study or read books and develop sharp expertise in particular technologies is important to you, then keep doing that. Someone, somewhere, will need your skills, and then you'll be the guy that knows X better than anybody else.

Think of it like dating, yeah? You look around and think, "wow, everyone likes guys with hair gel, I guess I need to use hair gel too", but it's a big world, and there are lots of people that think hair gel is gross. Maybe instead you practice having a great smile or being friendly, and that gets you happiness instead of hair gel.

Maybe you've hit real lows because you've been comparing what you do to what other people do and then deciding that what you do sucks because they get attention and you don't, so to defend what you want to do you're trying to convince yourself that what they do actually sucks.

But none of that actually matters. It doesn't get you any closer to happiness. Just do your thing and do it well.

[aerovistae]

Think there's a massive population of people on HN who either aren't developers at all or who are aspiring developers looking to get better. There's a lot of top devs on here to be sure but I would handily bet you the ratio is at least 2:1 (not top):(top).

[jordanpg]

As others have indicated, you're presenting a false choice. Surely, "solving problems" and "getting..code out the door" are the same thing.

Top developers are identified as such because they are getting results, by which we mean "decent or better, properly working software".

That's it. No conspiracy, just results.

[chrisallick]

Two options. 1) My guess is these people care as much about problem solving as yourself, but their problem is bigger than the code they are copying and pasting. So it appears as if they don't care, but they just care about something else. Lazy makers/coders often worry about the final solution and reflection time rather than how every line of code works. 2) they suck. which happens, fuck 'em they'll be gone eventually when they can't cut it.

The ultimate answer to your question is to stop looking at the people you don't like wondering why they are the way they are. Find the inspiring people, even if they are few and far between, and latch on to them.

[Retric]

Your looking at to low a level. Nobody can google how to solve the problems people actually care about. What people find online is basically just the manual that nobody writes anymore.

I suggest you pick a relevant book to read every month on your own time. But, while your working is generally not the time to be doing that kind of learning.

[byoogle]

I used to work at Google, with some of whom many here would consider the “top developers”. I can assure you that they didn’t copy and paste googled code. ;-) You haven’t worked the best developers yet. If doing so is important to you, focus on improving your skills and find a better job.

[joe563323]

Wow its really nice to hear from google level developers. Could you please tell what would they do as opposed to copying some function which is readily available from SO. May be google engineers never use SO except for Jon Skeet :)

[tootie]

I'm a "Senior Architect" at my company which involves various daily responsibilities (sometimes coding, sometimes scrum master, sometimes client meetings) but ultimately I'm accountable for delivering the final product. The ultimate driver is always to finish the project moreso than to do something cool and find the ultimate gleaming elegant solution. It's almost always best to choose a approach quickly rather than spend weeks and weeks evaluating. Secondly, choosing a cutting edge technology or really anything you're unfamiliar with is a major risk that your timeline probably can't absorb. I don't have all the answers. In fact, I'm probably pretty behind at this point because I'm lucky to spend half my time looking at code. If the youngsters on my team have some new approach that they think will work and can convince me, I will definitely accept it. In fact, there are devs on my team successfully executing with a framework I still haven't bothered to learn. They're cranking it out with excellent results so I'm happy to leave them to it.

[gregthompsonjr]

It doesn't sound like you're describing top developers. Instead, you're describing really good script kiddies. The top developers are great problem solvers and, in my experience, are really good at remembering details and knowing when to apply those details.

Getting things done is huge, but grace takes a little more than the "get things done" mindset. Being a top developer is being a really good painter. Anyone can paint by numbers or look at a painting of a rainbow and take lots of time to copy it. But, not just anyone can paint the same rainbow without any such guidance. Both types of painters come out with the same result, but one did it employing techniques that may have been hard to come by and can't be taught. The painter who doesn't need said guidance is probably more valuable than their counterpart because the painter needs the least resources.

[Bahamut]

I have found that the best developers try to understand the code they write, even if it is only after writing a guess at the solution after Googling for the answer or a hint of one. I have found it supremely important to understand what you are modifying because otherwise you are throwing darts at the wall blindfolded.

You absolutely can care exclusively about getting out as much LOC as possible, but it is the wrong thing to care about if you want to improve as a developer & be more efficient in the future. If you are able to generally solve problems well, what happens is that as you work at them more, you become more efficient at solving them quickly and you write more valuable, difficult code quickly.

If I had to recommend courses of action to improve, it would be to work on solving difficult problems, and to keep practicing your craft. Don't worry about what others around you are doing.

[new299]

> developers most willing to guess about how code works, copy and paste googled code, and push others to feed them answers instead of doing research on their own are considered to be the top developers because they 'get things done'.

My guess would be that they're able to abstract out and isolate functionality they don't need to fully understand to work on the core code they need to write to get the job done.

In modern systems there are so many frameworks, libraries, platforms etc. that if you try to gain a detailed understanding of them all you don't get anything done.

The core skill in modern engineering is knowing how to proceed with incomplete knowledge.

[JoshTriplett]

There's a balance here. On the one hand, you have to have the ability to figure things out on your own when nobody knows the answer; sometimes you do need to read through a pile of undocumented "legacy" code and puzzle out what it does. On the other hand, no one person can know every last detail of a twenty-million-line codebase; you're going to have to be willing to work on codebases you don't fully understand, and do the best you can with what you know. That doesn't mean people working on such a codebase are not "interested in learning everything they can about development", or not "caring about solving problems". However, there's a balance; you can't be so busy learning that you never take the time to apply what you've learned; knowledge.

You definitely shouldn't be focused on "getting as many lines of code out the door as [you] can"; if you think that's what your employer and co-workers expect, then either you aren't interpreting it correctly, or you need a new employer and co-workers. However, you should be focused on being as productive as you can. Develop a reputation as being the developer who almost always knows the answer to whatever crazy question their co-workers have, or who knows a little something about almost everything; those people are invaluable in an organization. And in the meantime, don't forget to actually write code.

[davidst]

There is nothing wrong with you. You are working with the wrong people.

[znpy]

I came to think that many, many times deep understanding an elegant, well crafted solution are just an exercise of style, not really needed, and not actually needed (often a waste of time).

And __DON'T__ get me wrong on this: I love understanding how things work and write beautiful code.

The thing is: you're working for a company, and let's say you're using $language and $framework. You have the deadline in a month (or two months, or n months).

You come across a problem. And here the kind of company you're working for makes the difference.

If you're working for a small or medium sized company, maybe it's just better to google an answer and do some copy-paste from stack overflow. Small-sized companies have more interest in getting things done than anything else. Typically.

If otherwise you're working for a big company, you're developing code which will be used by thousands (millions?) of users and your company has (or wants to establish) a role in the open source industry, then you sit down and examine the bug, you examine the stack traces, you fix it, and maybe submit a patch. Not only that, you also want to make your code as fast as it can possibly be. Because saving 2% execution time on two servers may not be that interesting if you have to spend three weeks, but saving execution time on 300 or 400 servers (or more)... Well, that matters.

As many other said, it's all about compromise.

You may want to consider applying for a position to $big_company.

[gumby]

It depends a lot on management and culture.

One of the best developers we had at my first company was a guy who could literally "fix" almost anything. If the dam was leaking and the village was threatened he could come over and stick his fingers in the holes and save the village in no time.

But someone had to come by afterwords and fix the dam properly.

Was he awesome? No question! Were we all glad and grateful that he was part of the team? Yep, everybody loved him (well, he was an awesome guy as a person too). He saved projects in trouble, solved customer emergency bugs etc. But we had a bunch of developers who kept up with the literature, could conceptualize solutions to complex problems, work together to get crazy-hard problems done, and they were clearly the "top developers".

Some management only appreciates the short term, and for them the "copy and paste googled code" guys are the best.

BTW there's nothing wrong with looking up a solution in Google. But consider it like the kitchen: when I am making a dish I often look up several recipes or techniques, then use the tools and materials I have at hand to make a meal. The more understanding and experience you have, the more value you get out of looking things up (and the less often you end up doing it).

[DanielBMarkham]

I had an interesting conversation with a developer on another team a while back.

The team had a client that wanted them all to cross-train to do both web and droid development. The developer thought this was horrible. We have developers here that have decided they want to become an expert in Java. So why should they be asked to do web development? Or droid? Shouldn't the client just add to the team?

As sz4kerto points out in another comment, the problem here is that people tend to define the problem in their own personal terms instead of the larger context. The larger context here was: The client has money. They are willing to train you to learn all kinds of cool stuff. In return, they want to share with you the larger business problem in hopes you can help them solve it.

Thinking in terms of the technology (or solving some technical problem) really misses the boat with what goes on in a lot of development teams. The "people part" of development is far more important than anything else. Find out what sort of people problems you are being paid to solve. Focus on that (while doing a good job technically, of course).

[PaulHoule]

Giving you advice about being a programmer is like giving career advice to an actor, musician, writer or other creative person.

That is, there are many ways you can be successful as a programmer and that different workplaces have different attitudes about what a good programmer is.

For instance, sometimes the best way to learn something, be you working on Greenfield or legacy code is to think about it a bit, make an informed guess about what to do next and do it.

You can answer surprisingly many questions in a technical job interview with "look it up in a hash table" and "look it up in the literature." Any research project starts with a literature review, so there is no problem at looking at what other people of done. In fact, sometimes I hit a StackOverflow page where I get to choose between 10 or 20 options, some with a good explanation of the theory.

Similarly there is nothing wrong with getting help from other programmers. If somebody can tell you in five minutes what would take you five hours to do on your own, you vastly increase your value and productivity by reaching out.