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.
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.
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.
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.
Fair use is a pretty subjective thing that's up to a judge to determine. It's a four-factor test, and you can read more here: http://fairuse.stanford.edu/overview/fair-use/four-factors/
* the purpose and character of your use
* the nature of the copyrighted work
* the amount and substantiality of the portion taken, and
* the effect of the use upon the potential market.
The fact that it's 2-4 lines may come in as part of factor 3, but the other factors also need to be taken into account.
If something I wrote, even just a few lines, is used to generate profit for someone else, and I did not permit that or place it in the public domain, I'm not sure a fair use claim would hold up. IANAL.
For example, the first factor (purpose and character; transformative nature of the work) is often less transformative in commercial settings. The fourth factor (the effect of the use upon the potential market) is also often more challenging for commercial enterprises to get past.
However, there are plenty of commercial enterprises that rely on fair use regularly. News media is a very common commercial product that relies on fair use.
Copyright and fair use law is pretty much the same for commercial and personal products. If you can make a compelling case to a judge around those four-factors, it can be fair use.
However, when taking clippings from SO and using them directly in a software, you're going to have very hard time making a fair use claim — wether it's for a personal or commercial project.
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.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.
http://blog.stackoverflow.com/2009/06/stack-overflow-creativ...
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.
What about Don Knuth who wrote TEX for a decade ?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 :-)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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!
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.
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.
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.
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.
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.
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.
'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.
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.
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.
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.
All these require a different mindset and different approach. There is not one way to become successful.
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.
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...
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.
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...
So I described the status quo in the industry... but if you can somehow move beyond that, that's very valuable territory.
Perhaps the people you've seen are not, in fact, very good?