Timeline for I'm graduating with a Computer Science degree but I don't feel like I know how to program
Current License: CC BY-SA 2.5
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 4, 2011 at 19:54 | comment | added | iyerrag | +1 for the comment. But that said, there are a lot of alpha-programmers/leads/managers out there who insist on home brew solutions. So who knows, maybe you have to write everything from scratch, which might not be the best thing either because of timelines and parallel work. | |
| Feb 4, 2011 at 15:07 | history | migrated | from stackoverflow.com (revisions) | ||
| Feb 4, 2011 at 13:55 | comment | added | Lloeki | "If I have seen a little further it is by standing on the shoulders of Giants" (Isaac Newton). There's nothing wrong with leveraging the work done by hundreds of others before, especially when it makes the whole thing go forward. | |
| Jan 27, 2011 at 5:42 | comment | added | Bogatyr | After you've (re-, re-, re- )implemented (and re-, re-, re-debugged!) a linked list or a dynamically sized array or a hash table dictionary in C / C++ for the umpteenth time, you will cream your jeans when you discover the STL and Boost. I've never (re-) implemented (and re-debugged) a basic container since coming up to speed on the STL. Using libraries as your "primitives", as opposed to just raw code, brings your game up to a whole new higher level, just like using a HLL does over using assembly language. | |
| Jan 26, 2011 at 8:51 | comment | added | volkerjaan | Reusage is most important principle in programming. The ability to find code that does something is even more important that ability to write it yourself. | |
| Jun 29, 2010 at 3:28 | comment | added | James Lin | gluing libraries up is not a bad thing, however you should have a passion that always want to find out how the fundamental works. | |
| May 29, 2010 at 0:19 | comment | added | Frank Farmer | A lot of programming is knowing how to find and evaluate libraries to address commonly-encountered problems. e.g., if you're writing an XML parser from scratch, you're probably just redoing work that someone else has already done better. | |
| May 18, 2010 at 13:28 | comment | added | TM. | @Joe maybe they just want to know how it works? | |
| May 15, 2010 at 3:07 | comment | added | Joe | Almost all of my 'real programming' jobs have had 'analyst' or 'engineer' in the title (a few had 'programmer/analyst'), but the point is -- knowing the libraries so you can identify what's already been solved so you're not coding from scratch every time. I want to scream every time I see a question of the form 'how do I do X without using Y_library?' without a good explanation of why Y_library isn't a valid solution. | |
| May 14, 2010 at 14:16 | comment | added | David R Tribble | This is actually the benefit of software reuse we keep hearing so much about. | |
| May 14, 2010 at 13:41 | comment | added | Atømix | When I'm not gluing together libraries, I'm usually making libraries that I will later glue together. | |
| May 14, 2010 at 4:46 | comment | added | Arnshea | echoing the comments of others, you spend a fair amount of time gluing together libraries because no one pays you to solve the pristine, simplified problems you train on in school. That training helps though, often in ways that are hard to predict. Like any other mature discipline there's a large body of existing work that you leverage to produce results. | |
| May 13, 2010 at 20:07 | comment | added | CodexArcanum | Definitely like 90% of my work is either hooking up other people's code (libraries or legacy code) or maintaining older code. But I spend my extra time learning bits and pieces as I go, so that now I do know how a lot of those libraries work, and have a much deeper understanding of what goes on under the hood in general. Be a lifetime learner, and you'll pick it all up eventually. | |
| May 13, 2010 at 19:18 | comment | added | AngerClown | Any integration work is an opportunity to learn more about what your are gluing together. If you can learn the why, not just the how, it can put you a step ahead. Become the person on the team who understands the library, then you can become the person who extends it or creates something really new with it. | |
| May 13, 2010 at 16:24 | comment | added | Hans Westerbeek | And there is nothing wrong with just glueing together libraries. That is what makes you productive! | |
| May 13, 2010 at 13:18 | comment | added | b_richardson | I agree there are some edge cases out there but I would say that 75-80% of the programming jobs out there are the kind where you are just gluing libraries together. | |
| May 13, 2010 at 2:10 | comment | added | Dan Bryant | @R0MANARMY, there's definitely always room for innovation and improvement. The key, in my mind, is never to forget the goal that these innovations are meant to further: a happy customer. There's merit in novel accomplishment and there is also merit in the skillful integration of the supposedly mundane. | |
| May 13, 2010 at 1:36 | comment | added | R0MANARMY | Depends on your goals. People who work on compilers are in the business of inventing tools for example. | |
| May 13, 2010 at 0:31 | comment | added | Dan Bryant | +1 for glue. Nobody would hire a group of professionals to build a new home and expect them to invent brand new techniques in home building in the process. In fact, anyone interested in managing risk and budget would probably prefer they not do that. | |
| May 13, 2010 at 0:02 | history | answered | dbyrne | CC BY-SA 2.5 |