Secrets you should have learned before your first programming job

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.

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.

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.

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.

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.

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.

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.

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?

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

Nitpick: The PHP function for setting error message levels is error_reporting(), not set_error_reporting().