17
votes
Advice for those who want a computer science career?
Those that have pursued a career that deals with any type of computer science, what advice would you give to students before they get a job in it? What do you do on a daily basis? What would you have wanted to know before you started?
A few quick, kinda-pithy pieces of advice:
Regular expressions are one of those things that you put off really learning for years until you finally get frustrated and bite the bullet to properly learn about them because not using them would be an even worse pain in the ass for solving the problem you need to solve, and suddenly you start to "get" them and kick yourself for not drilling them into your head sooner in the first place.
Seriously. Get comfortable with regular expressions. They're wonderful.
I will add another couple of items to this already awesome list:
Always make time to explain things to more junior people.
Learn to explain difficult things in simple terms. A good way to practice this is to explain CS things to non-CS people. I still struggle with this every day and I am in awe of people who can do things. (My non-technical friends wanted to know about 'blockchain'...)
Don't disparage people for using the 'wrong' operating system or 'wrong' programming language. Everyone works differently.
DRY: Don't Repeat Yourself. If you find things that you're doing repeatedly, script & automate it.
KISS: Keep It Simple Stupid. Don't make things overly complex.
Never stop learning. I cannot stress this enough.
Build a network both inside and outside of the company you're going to work for. Unfortunately, 50% of getting a (new) job is knowing people, the other 50% is skill.
Don't be afraid to ask for help.
LEARN ABOUT SECURITY! SQL injections, cryptography, hashing, XSS, CSRF, service authentication, etc, etc...
And a great way to learn Git is to sign up for Github (or another free public Git website like BitBucket) and put projects you're working on up there. That'll help you build a portfolio that you can easily share with potential employers.
A fantastic resource for learning and testing regular expressions is regexr
About that clever solutions way : for my thesis I had two ways to count something : using Maps and just using an array and it's indices. The maps were extremely slow (I had a lot of data to analyze) so the more clever way using arrays was the better option, even tho it was harder to read. Might be a specific example but I definitely agree it should be understandable - using fitting names for the function, variables - and with such weird snippets, you should document what you're doing
The important part is that you used the clever approach to solve a specific problem that you had. I'm not saying that people should never do anything complex, the issue is when people write clever code just for the sake of writing clever code, when a simpler approach would have worked equally well.
I'm learning C++ right now and I absolutely hate unnecessary (from a technical perspective) white space.
I try to make it readable against my urges but one day I might break down and put the whole code on a single line.
For example, I'd never write
rather than
std::cout << *i++;Assuming you’re in school now, make sure to get a summer internship the year before you graduate. On a more general level, always think about who you’re making software for and how to help them. Don’t say “no” just because something is hard—if it will make a difference to the experience of the people using your software, it may still be worth doing. Avoid programming ideologies which make you say “no” for purely architectural reasons.
Here's a really good recent blog post about that: How to teach yourself hard things
Understand one thing right now: in any area of CS, the #1 skill you'll be exercising is your problem-solving abilities. Whether you're writing code or a thesis, the written solution is merely you putting the result of your problem solving into a formal proof.
With that in mind, my biggest tip for you is to learn how to effectively solve problems. Don't just randomly change things until you get something that works, but follow a rigorous process for deciding why your solutions are wrong and what needs to be changed. Hypothesize, experiment, analyze, revise, and repeat as necessary. If you can do that much, you'll do well whether you decide to head into theoretical areas or practical application.
A big one is, don't feel like you have to take a computer science program. They have more honed in programs now. When I graduated high school all they had was computer science but I wanted to do systems, networking and security. So I went to a smaller school just to get a degree and then taught myself on the side.
And don't get let down if a lot of what they teach you is just Theory. The field changes so rapidly you have to study on your own and set up an environment on your own. People I went to school with expected them to teach them from the ground up and that just wasn't possible.
Not in CS but I do have some helpful advice!
One thing that I did before going to graduate school was to reach out to people in the industry/field via LinkedIn and set up informational interviews.
I sent out probably 10 messages and ended up having 9 over the phone conversations. One of the conversations that I had ended up helping me land an internship. In addition to the feedback you get here, you can always create a LinkedIn, creep on user's you want to be after your education, and use that as a benchmark. Plus, it gives you a place to put your portfolio when the time comes to do some job hunting.
I kind of did that. I looked at job ads and looked at the list of requirements for the jobs closely related to what I wanted to do and then I learned about those requirements and anything related and while I was in school I made sure to study those requirements on my own and ask professors that were in the field about them.
I basically just took lists of wanted skills from job ads and learned what they were and experimented with them and my own environment which was basically a Compaq Core 2 Duo.
By informational interviews, do you mean just messaging anyone that seems interesting and asking if they would be willing to answer a couple of questions? How did you approach them?
Are you a student (undergraduate? graduate?) now, or thinking about going into computer science?
More importantly, by computer science, do you mean programming, or the scholarly field of computer science?
In part, I ask because much of the advice here is about programming and development, not computer science itself.
Not only that, but if OP goes into industry, do they have a particular type of software that they'd like to work on?
I am in high school now. Sorry for not being more specific, but yes, I do want to do development. I'm hoping to get into game development, and possibly design!
Learn your limits in your problem solving process. One of the biggest weaknesses I've seen in other developers is to not know how to ask for help when they need it. You never want to stew on an issue for way too long, it doesn't make you look good and is not constructive for anyone. Mostly everyone I've ever worked with is always willing to help take a look at an issue.
Lots of good comments in here. The only thing I'd add is that you need to cultivate what I'd call 'systems thinking'. What I mean by this is that you don't want to work on projects in a silo of focus.
Out in the working world, stuff you build will 99% of the time be part of some larger system or use case than just the widget you are directly responsible for or working on. One of the things that sets great engineers apart is the ability to keep the larger picture in mind for consideration when they're producing work. Not thinking about that while designing a solution or building something is the #1 cause of frustration and friction. It's also a great way to continuously learn, and in some cases even stay ahead of your own project allowing you to anticipate what might be required.
Many decisions and direction will come from non-CS people. Many times Project Management/Product Owners/Managers are not nearly as savvy tech wise, but are still the ones setting the vision for products. Combining a good systems thinking mindset with the advice already posted here will make it MUCH easier to help direct good decisions and produce better work with less frustration.
I think learning how to pick up and understand new technologies quickly and thoroughly has been the most useful to me. To me the most useful way to do this is to start to understand the broader technology/computing landscape from the prospective of problems you encounter and then fit things into that landscape as solutions that make different tradeoffs. This way when you need/want to use something new you can see where it fits in quickly, make comparisons to existing systems you know, and highlight the areas where this new thing is different. Being able to understand this landscape and compare different possible solutions at a high level pays off time and time again in real-world engineering.