

Secrets you should have learned before your first programming job - nreece
http://blog.newrelic.com/2014/06/03/10-secrets-learned-software-engineering-degree-probably-didnt/

======
DigitalSea
I wouldn't call these secrets. Source control isn't a new thing, we've had
source control since before I was born. I think chances are if you're taking a
course for programming, you'll already know to use source control or quickly
find out about it.

I am confused. The article says developers need to learn regular expressions
and then goes on in the next point to basically say libraries have made
regular expressions irrelevant and that you shouldn't reinvent the wheel. I
rarely ever need to use regular expressions, I don't know them that well and
it hasn't prohibited me in my career. Maybe before the Internet existed and we
didn't have StackOverflow would it have mattered, but I can find an answer
quicker Googling than I can thinking it up sometimes.

I partially and respectively disagree with point number #5 the database
landscape is a lot different than it was 10 years ago. We have numerous
choices now like NoSQL derivatives, graph databases and more. You don't always
need to write SQL and flat file databases aren't dead, isn't that what SQLite
is? I still use SQLite in some cases because it's convenient. It's not
uncommon to find yourself on a project that doesn't need SQL queries at all,
and these days if you use something like Ruby on Rails or Laravel (PHP) in
combination with MySQL or Postgres you'll more than likely finding yourself
using an ORM and not writing queries at all. It is how it is.

Point #6 — if you're a decent developer nowadays, I would hope you either pick
something like Sublime Text Editor or Vim. I don't think teaching students
what IDE's and editors to use should be in a curriculum. Everyone works with
what works for them. As long as you can achieve the desired results does it
really matter if you're using Notepad? As long as you can write code without a
WYSIWYG, I don't think it matters if you used a typewriter. The development
industry is time and results focused, not tool focused (at least not in my
experience).

The whole point of a degree is to teach you the underlying concepts of
programming. You don't get taught how to interact with a client, you don't get
taught teamwork and I think that is okay. Some things are better left to the
real world, nothing educates you faster than a real world situation. You learn
the most important aspects of a programming job when you're on the job. Every
workplace is different, you can't account for all of the unplanned and
unexpected variables that come with a job in an industry like ours.

At the end of the day in a programming position you're nothing more than a
talented Googler with an understanding of the basics. I don't know everything
about my chosen languages, I do however know what to search when I need an
answer to a problem I am having. It's all about knowing what to search a lot
of the time I find.

------
Chromozon
Recent graduate with a 4 year computer engineering degree, here.

\- Source control was never mentioned in college. None of my professors
discussed how large groups of people code together on a single project. Now
that I'm working, Perforce has become my most frequently used tool.

\- Greater than 90% of assignments were writing code from scratch. In the real
world, the problem is more along the lines of, "Here is code that was written
5 years ago by a guy that no longer works in this department. Figure out how
it works and add this feature." The one assignment in college where the
professor gave us a bunch of code to start with was the assignment that gave
people the most trouble. The professor said, "The code does this, this, and
this. Your job is to implement this new thing." Many students in the class
could just not wrap their heads around how to do it. I worry for them once
they get jobs.

\- We did not do enough library usage in college. Most of the assignments had
us writing things from scratch. While it is important to know how standard
containers and well-known algorithms are implemented, once you get to the
workplace, all of this is done for you. You don't need to write these pieces
yourself because they are already implemented in a standard library.

------
happycry
Most - if not all - of these "secrets" are already included in the Computer
Science/Software Engineering curricula.

At least they were in mine.

Still a good group of points for aspiring engineers.

~~~
jinushaun
These things weren't included in my official curricula. Maybe over-achievers
in the class learned it on their own, but if a CS degree is actually supposed
to represent something of value, it should at least teach these basic
industry/vocational programming skills. You graduate college treating
programming tasks like homework when the real world is far from it.

------
dugmartin
Most of these seem like technologies - instead I think learning about
estimation, technical debt, project fatigue and human communication strategies
would be better "secrets" to learn.

~~~
altcognito
Estimation is about experience, and not just any experience, probably
experience related to the domain. And honestly, with good agile practices,
estimation isn't as critical as it used to be because you're not going to be
the only one on the team, and hopefully, you're not all new.

Otherwise, can't agree more.

------
clubhi
Success is complicated. If you are a big company success often means getting
promotions and raises. At a small startup success might mean getting the
company acquired.

When success depends on pleasing your boss or peers it really has more to do
with their check list than any list like you created. Different people value
different things.

When success depends on getting a company acquired then sometimes having all
your bases covered is very helpful. Other times you might be able to write
your whole product with Vim and never needing anything but a python and django
book.

I'm bringing this up because I'd hate to see young students try to "catch up"
by learning these technologies. Try to focus on what you enjoy.

------
LesZedCB
I never really learned those things in school, and I just graduated this May.
The closest that we could have come to adaquate discussion of one of those
topics would be the databases elective, though i didn't take that one. We gave
a 5 minute presentation about different VCS's once in senior seminar, that was
it. Fortunately I learned all these things from my own projects or my time
working in actual companies. That being said, I don't think any of the things
in this list are particularly hard to learn. Also, college is really about
teaching you how to think about a subject, and a lot less about how to be a
successful professional in one, even one so "practical" as computer science.

------
basseq
I would say my CS degree (if memory serves) covered all these except version
control, which I agree is an omission.

1\. Version Control - Really no. I think we talked about it, but it should
have been one of those CS201 things that was then required through the rest of
the curriculum.

2\. How to Write - I had great high school English teachers, which helped, but
undergrad also had a) a written thesis requirement and b) "STS" (Science,
Technology, & Society) that emphasized non-technical disciplines.

3\. Regular Expressions - I _feel_ like I learned formally in college, but may
have taught myself.

4\. Libraries - Yes, absolutely, in a variety of languages. There could have
been more here, but you have to balance knowing how to write quicksort (which
you may be quizzed on in a job interview, after all) with the standard sort()
algorithms. There's a lot of nuance here.

5\. SQL - Database was an elective, though one I think a lot of people took.
Agreed could be earlier and required.

6\. Tools - We used an IDE (Eclipse for Java, e.g.) from Day 1. We had
required courses that required 100% remote execution on a Unix cluster.

7\. Debugging - Kind of learned throughout, I think.

8\. Defensive Programming - See #8.

9\. Teamwork - Big check. Multiple teamwork requirements across all classes.

10\. Existing Code - We re-wrote part of Windows 95. How's that for legacy
codebase?

The big thing to remember is that a CS degree is not a "Programming" degree.
Yes, most CS majors are programmers, but they are also more. Things like
linear algebra, physics, graphics, hardware design, statistics, data
structures, probability, distributed computing, and algorithms all contribute
to a high-level computer _scientist_.

------
forrestthewoods
I've been programming video games professionally for over 7 years (C++). In
that time I've never had to touch SQL. I feel like this is a big hole in my
knowledge. I'd like to fill that hole. What's the best resource for a
competent, professional programmer to learn?

~~~
mwilkison
It covers more than just SQL but
[https://www.coursera.org/course/db](https://www.coursera.org/course/db) is a
good overview.

------
incision
Interestingly, many if not most of these items are covered in CS169.1x [1]
over on edX.

Also, my recent 100-level courses at a continuing education arm of a public
university covered 1, 6, 7, 8 and touched on 2 and 10.

In my experience, the most consistent omission is #2 'How To Write'. It's so
rare that my own limited, but apparently good enough, ability has been a
significant bonus throughout my career.

1: [https://www.edx.org/course/uc-berkeleyx/uc-berkeleyx-
cs169-1...](https://www.edx.org/course/uc-berkeleyx/uc-berkeleyx-
cs169-1x-engineering-1377)

------
chrishepner
Nitpick: The PHP function for setting error message levels is
_error_reporting()_ , not _set_error_reporting()_.

