
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&#x27;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 &#x27;get things done&#x27;.  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&#x27;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.

~~~
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.

~~~
ams6110
Is there not a blanket/implicit release of claim that goes along with posting
code on SO?

When I copy code verbatim from SO or another "help" site, I generally put a
comment right above that chunk of code, something like:

    
    
      /* See: http://stackoverflow.com/a/xxxxxxxxxxx */
    

Don't know if that's enough to protect against any ownership claims though.

~~~
jdotjdot
I think this is helpful more in helping future developers reading the code
have more context about what the code is, why it's there, and where it came
from, rather than anything to do with ownership claims.

Often times code taken from SO solves the problem but noticeably is structured
differently from the rest of the codebase--often with good reason--and this
helps the new dev go look back at the SO conversation and see what problems
this is solving / if it can be removed.

------
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.

~~~
ams6110
I have some experience in academia and I mostly see the extremes: either
blatant wholesale copy/paste as much as possible, or an extreme "not invented
here" attitude, refusal to use existing solutions, a sentiment that everyone
else's code is useless crap, and a lot of reinvented wheels.

------
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](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.

------
pjscott
You're looking at the top of the bottom -- at the people who excel at
programming tasks so undemanding that they can be solved largely by copying
code from the internet and modifying it slightly.

Now imagine one of these "top programmers" trying to write something like --
and I'm pulling this out of a hat -- Redis. It's a database that stores the
entire dataset in memory, has a handful of useful data structures (e.g. lists,
sets), and lets you do a bunch of operations on them via a network. It
supports master-slave replication. It can persist to disk either by
periodically flushing the current state or by writing a log of all commands.
It can handle very large numbers of open connections. It's extremely fast, and
widely used. Can you imagine the looks of frustration on your colleagues'
faces when they try to google how to make something like that, and their
searches fail to produce usable code? Not all problems are like this, but many
are.

Real top programmers tend to wind up with tasks that they can't just google.
Don't lose hope!

------
ilaksh
Programming isn't computer science, so that can be misleading coming from that
into programming/software engineering.

Also, programmers may write a blog article that represents a perfectly crafted
solution and present it as the norm even though they really have to settle for
hacks in their day job.

And people will often present themselves as being experts in a subject when in
reality they just found out the technology existed two days ago. No one can be
an expert on every new system or even most of them. The most relevant
technology is often something new to learn.

Also, different jobs vary wildly in terms of schedule, how much time there is
to experiment with solutions, how much actual factoring/testing/engineering is
expected, etc. Most project phases or jobs in general fall short of the ideal
in this regard.

Also, people may have just plain misrepresented to you what effective
engineering actually is.

I think to be effective at solving tech problems you _have_ to guess and then
see what happens and then adjust. That's what engineering is. Its based on the
scientific method.

Physics is complex, especially information technology. And you can't develop
everything from scratch. You have to take advantage of other people's work,
guess how it will fit together best. But it is always a guess because the laws
of physics make it impossible or impractical to figure out what the system is
going to do without running it first. So you try out different ideas or
designs and adjust. In a feedback loop.

As far as getting lines of code out the door, you want the fewest lines of
code that are practical given time constraints on factoring. The ideal might
be no lines of code sometimes when you can use an existing solution.

Anyway, yes, they are guessing, because of the laws of physics.

------
TYPE_FASTER
Top developers do not guess at what code does, they step through it, or add
logging, or sit there and step through it mentally until they understand what
it is doing.

Top developers do not copy/paste code snippets off the web, they use googled
code as examples to write their own code that works with the code they are
working on.

Solving problems based on guesses takes more time than understanding the code.
It looks and feels more productive than sitting and thinking.

There is nothing wrong with somebody providing an answer, as long as they can
explain the logic or lack of logic behind it. Why have multiple people go and
figure something out? Post it on a FAQ on the intranet so everybody
understands. If they can't explain the answer, ask to see the data and go
through it together. Maybe everybody will learn something.

There is nothing wrong with getting things done, as long as they are done in a
way that won't get in the way of getting things done in the future.

------
geofft
> 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?

You need to _start_ caring about solving problems. If the way to get a problem
solved is to Google something and copy and paste a few lines, _solve the
problem_. If you want to spend years letting things into your brain but not
out, there are plenty of useless corners in academia.

That said, if the top developers you see are uninterested in learning more,
you're working at a bad company. Which is not particularly uncommon: good
developers go work where other good developers and good management are, and at
the places with bad developers and bad management, there are still people who
are at the top of that company. Top developers _are_ good at finding answers
by Googling, but that's a way for them to learn, not a way for them to avoid
learning.

------
Delmania
"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"

There are some Nobel prize math winners who can't do simple arithmetic. Why
would they? They have access to computers and calculators. Do you honestly
need to know how quick sort works? Do you honestly need to know how to do a
binary search?

More than likely, the answer is no, the runtime you're working in has those
operations implemented, and they're more robust than anything you can do. You
need to know WHEN to use them, but outside of college, knowing the specifics
is pointless, except for coding interviews.

You have bigger problems to solve.

------
sshine
Not as many lines of code as possible - less is more - but as many issues
closed as possible. Good developers are focused on the goal. The developers
that I've admired the most over time just had a knack for thinking clearly and
addressing problems in ways so that future code paths align well, too.

------
totoroisalive
If you’re really successful at bullshitting, it means you’re not hanging
around enough people smarter than you.

------
brudgers
A year in most industries doesn't really provide the death of experience
necessary to make informed judgements. My advice is that when something
doesn't quite add up is to presume that I don't have the big picture. If I
were in your shoes, I'd wonder about how the business model drives behavior.
Consulting is different from product development. Operations in a cost center
are different than in a core revenue unit. Companies that compete on price are
different than those that compete on specialized expertise and different from
those who operate on socializing in the good old boy network.

This is the time to learn. It may be that you are working in a soul sucking
workplace. But still reach for a deeper understanding not easy assumptions.

Good luck.

------
napperjabber
There are employers that what you to think the way you're thinking.

There are other employers that want you to copy the other guy before spending
time in the details.

Adapt to the situation, find what you like in your off time or find a new job.

Learn how to talk to people and people will protect you. If you keep telling
everyone else they're doing it wrong, no one will think you're helping them
because you're being negative. Point out something you like.

I write circles around some of my coworkers, but they talk-circles around me
in social dynamics. Everyone is good at something. Talk about what they like.

Find a reason to like the person you're working with. Don't be combative, this
won't be the first time someone 'thinks' you're doing it wrong. Humility is
key.

------
petepete
Depends on how you define 'top'. If you mean the ones who rise quickest
through the ranks of a company that's not technology-focused, then maybe
you're right. In the long run, however, the cream rises to the top. People who
genuinely don't know what they're doing are uncovered.

'Guessing' isn't always a bad thing, either - providing it's an educated
guess. Of course, there's an argument to be made for understanding every last
line of code, every component and module in a behemothic application, but in
the real world, it's just not the case.

------
BerislavLopac
> considered to be the top developers

The important point here, considered by whom? My guess would be the management
who in this case cares about "getting things done" without much consideration
for technical debt, which usually ends up biting them back.

So, you've learned that this one company has different criteria for success
than what was true in school, but there are many companies, with different
cultures and different criteria. Don't get discouraged -- instead, actively
seek good quality developers, go to meetups and other events, and even change
companies if necessary.

------
arihant
Seriously, I copy/paste code all the time. If I'm writing a complex newsfeed
algo and I need to write a sorting function. 9 times out of 10 the sorting
function I need is easily googleable for my language. As much as I love to
code, why would I waste my time writing it again? Yes, I wrote it in college,
I loved it very much. But I won't deviate my focus from my newsfeed that I'm
building.

It's not much different from using a library. Understanding is fun, but
reinventing a wheel can be a serious violation of prioritization.

Put in other words -- you must choose your battles.

------
yankoff
I think prioritizing and focusing on the right thing is one of the skills
senior developers have. You don't normally have one isolated problem to solve.
You have a problem and it branches out into multiple other problems. Over time
you just learn to estimate the importance and the time you can spend on each
problem to get things going. So you do have to have a deep understanding of
the important part, but you cannot go into too much detail for every single
sub-problem you have, otherwise the productivity will be very low.

------
bikamonki
I am sure someone famous once said: it's not about knowing something, it's
about knowing where and how to find.

Typical scenario. \- Product owner: can we compress images before upload? (I
have not done it before but after a quick analysis I know we can) \- Me: sure

Two hours later we had a new feature. I am not a top developer b/c I am not
sure if my copy/pasted lego pieces have some serious security issue or will
fail a test I did not see (I do read ALL comments and answers on SO to avoid
obvious holes). But the problem was solved.

You judge.

------
ma2rten
I think the answer to your question is that there is not one type of 'top
developer'. Some people are good at implementing features fast, some at
designing scalable architectures, some are experts at designing algorithms,
some people know every detail about how a given system works (an api,
database, operating system, cpu) and some can find bugs very quickly in code
they've never seen before.

All these require a different mindset and different approach. There is not one
way to become successful.

------
Sir_Cmpwn
There are two kinds of problems.

The first is "I need to sort this list in Python". The second is the broader
application that list is relevant to.

When I'm coding, the first problem is uninteresting. Sorting lists is a solved
problem. I just google it and paste in code that does it, and it's done and
off my mind. The architecture of the broader application this fits into,
though, merits a lot more thought and the broader problems it solves again are
worth much more investment.

------
proksoup
Show them that you can get things done faster in the long run by slowing down.

The emphasis on speed (getting things done) is always short sighted, and they
know that. Help them see it.

[https://ventrellathing.wordpress.com/2013/06/18/the-case-
for...](https://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-
programming/)

------
damon_c
Understanding just enough to get things done, copying and pasting, and
building thoroughly planned and well designed fundamental libraries are all
just tools in a toolbox. Sometimes one or the other is the best tool for the
job. For best results, learn to use the right tool at the right time.

------
chipaca
He's on to us.

------
CyberDildonics
You need to to start caring about solving the right problems and not any
problem that has already been solved.

The best way to get things done is to re-use code. The best code to re-use is
something that hides lots of complexity yet has a simple interface.

------
chubot
You're experiencing what basically every smart computer science graduate does
when going off into the world and encountering codebases that serve customers.
They're huge and messy.

I had this same rude awakening at 22. You're used to dealing with 500 lines of
code; now you have to deal with 200,000 lines of code. Even 10,000 was too
much for me at that age.

Computer science is about being smart and understanding things. Software
engineering is about realizing how dumb you are compared to the task, and
developing strategies to control that complexity and manage your time.

The best programmers I've seen have these qualities:

1) They have simply exercised their brains enough to wrap their heads around
50,000+ lines of code. They know how to read code.

2) On top of that, they know how structure their code to avoid having to
understand all of it line by line. They write their code to facilitate
"chunking"', the same skill that a chess player uses to assess a board
position quickly.

3) They trade off time vs quality by sweating the details WHEN IT MATTERS. For
core parts of the program, it absolutely pays off to do original research. For
example, writing data structures for search algorithms or graphics engines.

But the data structures are less than 10% of the code in an information
retrieval system; the graphics engine is is probably 10% of the code in a real
game.

For the rest of the system, you need to plow through it quickly, perhaps
copying and pasting code from older systems.

Usually you have different developers working on these parts -- some people
are good at plowing through tasks; some people are good at working on well
crafted code solving a difficult problem. But the latter are usually
experienced developers in their 30's, not fresh grads at 22. At 22 you'll be
tasked with plowing through code.

After 13 years of professional programming, I think that "taste" is basically
learning what matters. Lots of things I obsessed over when I was 22 didn't end
up mattering. When you can only work on 1,000 lines of code at a time, you're
simply missing the big picture. So basically that's a thing you have to work
on to succeed as a developer.

With that said, there's also the fact that most software is shit :) Software
is shitty and in particular insecure due to its sheer size.

[http://steve-yegge.blogspot.com/2007/12/codes-worst-
enemy.ht...](http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html)

So I described the status quo in the industry... but if you can somehow move
beyond that, that's very valuable territory.

------
apu
That doesn't fit any of the best developers I've seen.

Perhaps the people you've seen are not, in fact, very good?

------
flaing
no. top developers care about only themselves, that means they won't copy and
paste others' code, they make algorithm their own! However they enjoy being
inspired from the code and try to optimize the code.

------
ExpiredLink
Copy and paste is the most basic form of reuse. Don't underestimate it.

------
pixie_
If you're not getting things done, then what problems are you solving?

~~~
toast_coder
^THIS^

~~~
pixie_
Its sounds good, but people like you end up over-engineering the solution. AKA
making it generic, extendable, etc.. It's pre-mature optimization, i see it
from a mile away.

