Ask HN: What advice would you give to a computer science undergraduate?
I am about to enter into the 2nd year of my CS course in university. The second year is when actual CS courses begin. I've had a basic C course. I have good knowledge of basic computer science, some algorithmic knowledge and a good experience with JavaScript and Node.JS. Yet, it would be great if I could get real advice / insights from professional computers scientists on things to explore ( in the CS field ) in college.
51 comments
The things that you think are going to take a long time will take a short time and the things you think will take a short time will take long.
So, for instance, if you have 4 hours scheduled to implement some neural network to optimize X, it may take 30 minutes to type in the algorithm and get it working, but it will take 3 hours to get the environment set up, the version of Tensorflow or whatever up and running, and much longer to type up your results.
So, hopefully, if you expect this, you won't crumple in despair when you find your self 1.5 hours into the time and you haven't even got the right language working with your IDE for that hello world to come up. No, you're right on track, and just keep going.
So, for instance, if you have 4 hours scheduled to implement some neural network to optimize X, it may take 30 minutes to type in the algorithm and get it working, but it will take 3 hours to get the environment set up, the version of Tensorflow or whatever up and running, and much longer to type up your results.
So, hopefully, if you expect this, you won't crumple in despair when you find your self 1.5 hours into the time and you haven't even got the right language working with your IDE for that hello world to come up. No, you're right on track, and just keep going.
- Make 1 web application
- Make 1 mobile application
- Make 1 desktop application
- Nothing fancy for the above just some that solve simple problems, good if they solve your problems!
- Learn to use a version control.
- Try to intuit with hands on coding a hard domain you will like: graphics, AI, compilers. The trick is if you like the hard parts, you most likely like it!
- See if you can work with some professor where you can learn how to implement code for papers published in the hard domain you like.
- By the time your internship arrives, you can build a decent portfolio.
- And eat, sleep, exercise.
I know the above can be a lot with your studies, hopefully you can pull it off. Good luck.
- Make 1 mobile application
- Make 1 desktop application
- Nothing fancy for the above just some that solve simple problems, good if they solve your problems!
- Learn to use a version control.
- Try to intuit with hands on coding a hard domain you will like: graphics, AI, compilers. The trick is if you like the hard parts, you most likely like it!
- See if you can work with some professor where you can learn how to implement code for papers published in the hard domain you like.
- By the time your internship arrives, you can build a decent portfolio.
- And eat, sleep, exercise.
I know the above can be a lot with your studies, hopefully you can pull it off. Good luck.
I would also highly recommend learning version control - GitHub has a good set of Git tutorials at https://try.github.io/, and http://ohshitgit.com/ is a handy reference for common mistakes/pitfalls in it.
Using version control regularly gives you:
* Backups in case of mistakes/system failure (so long as you remember to sync/push your work to an external server)
* Room to experiment with various approaches to a problem (since you can always reset to a known good state)
* Experience in explaining and structuring your solutions to problems
Using version control regularly gives you:
* Backups in case of mistakes/system failure (so long as you remember to sync/push your work to an external server)
* Room to experiment with various approaches to a problem (since you can always reset to a known good state)
* Experience in explaining and structuring your solutions to problems
Learn how to use your debugger. People will tell you things like "If you use unit tests, you never have to use the debugger!" but it's nonsense. When one of your tests break, you have to dig in and find out why it broke, and that means debugging. Plus a lot of things can't be reasonably tested in unit tests.
Take a class on ethics. Most companies hiring CS majors today are sorely lacking in ethics and it would be good to know ahead of time which are which.
Learn how to ask questions to get good answers. In particular, learn how to write up an MCVE - Minimal, Complete, Verifiable Example [0]. The better the quality of the question, the better the quality of the answer. This is really hard when starting out using a technology you know nothing about. In those cases, describing what you're trying to do, what approach you're taking, and why you think that approach is useful will get you to answers about how to do it correctly more quickly.
Don't spend too much time on HackerNews. The articles posted here tend to attract a certain crowd with a certain viewpoint on any given subject and it's a bit of an echo-chamber.
[0] https://stackoverflow.com/help/minimal-reproducible-example
Take a class on ethics. Most companies hiring CS majors today are sorely lacking in ethics and it would be good to know ahead of time which are which.
Learn how to ask questions to get good answers. In particular, learn how to write up an MCVE - Minimal, Complete, Verifiable Example [0]. The better the quality of the question, the better the quality of the answer. This is really hard when starting out using a technology you know nothing about. In those cases, describing what you're trying to do, what approach you're taking, and why you think that approach is useful will get you to answers about how to do it correctly more quickly.
Don't spend too much time on HackerNews. The articles posted here tend to attract a certain crowd with a certain viewpoint on any given subject and it's a bit of an echo-chamber.
[0] https://stackoverflow.com/help/minimal-reproducible-example
Study something else in addition to computer science, preferably in the humanities or social sciences. A lot of the problems we're seeing in big tech come down to the fact that the people working there don't understand anything outside of software development, and we'd be better off if they had wider and more diverse backgrounds.
Ideally you'd do your CS major in a liberal arts program rather than in engineering, but that might be impractical. Get as close as you can, though.
Ideally you'd do your CS major in a liberal arts program rather than in engineering, but that might be impractical. Get as close as you can, though.
Read (and converse) voraciously and follow the directions it may lead you... Into art, philosophy, psychology, business, politics, literature. This will help you to find things you love, it will also give you insight into adjacent topics that will allow you to shine in an area of CS that is right for you. You will never have such a perfect chance to do this as your university years.
Thank you!
What I would suggest is to actually take advantage of the environment that the university provides to you. Speak with professors, learn what they do, ask questions, potentially work with them, interact with students - generally try to learn as much as possible by exploring all the different sides of the comp. science world and most importantly, enjoy it!!!
If you want to go into academia:
Get very good grades especially in math and cs. Do research for credit or money. Get a summer research position. Don't worry too much about authorships your first year; you will hopefully end up as an nth author. In later years you're going to want to get a few nice publications (either high profile as nth author or ok-levle as first author) to get into a good grad school.
If you want to go into industry:
Prioritize getting an internship with a good company over all else. Get good at solving algo/DS problems. The big household-name tech companies will open doors for you if you have them on your resume, and they have special programs for freshman-sophomore students.
Regardless:
Take academic courses instead of practical courses. University practical courses (e.g. web dev) usually lag behind industry, and you will have ample opportunity in your career to learn new practical skills. You will probably never be in a state of mind or environment where you can get as much out of academic subjects (e.g. statistics, AI, theory of computation, etc.) as you are in now. Always always always prioritize conceptual understanding over trivia you can just google.
Get very good grades especially in math and cs. Do research for credit or money. Get a summer research position. Don't worry too much about authorships your first year; you will hopefully end up as an nth author. In later years you're going to want to get a few nice publications (either high profile as nth author or ok-levle as first author) to get into a good grad school.
If you want to go into industry:
Prioritize getting an internship with a good company over all else. Get good at solving algo/DS problems. The big household-name tech companies will open doors for you if you have them on your resume, and they have special programs for freshman-sophomore students.
Regardless:
Take academic courses instead of practical courses. University practical courses (e.g. web dev) usually lag behind industry, and you will have ample opportunity in your career to learn new practical skills. You will probably never be in a state of mind or environment where you can get as much out of academic subjects (e.g. statistics, AI, theory of computation, etc.) as you are in now. Always always always prioritize conceptual understanding over trivia you can just google.
> Take academic courses instead of practical courses.
I would caveat this with: Make sure you have some structured activity that forces you to write a bunch of code. If you're not competing in ICPC or doing something similar, you should be taking courses like Operating Systems, Compilers, etc. that require significant coding assignments almost every semester.
Theory classes like Discrete Math, Theory of Computation, Algorithms, etc. are great, but it's important to have structured practice to make sure you're developing your coding skills as well. Most students won't actually complete coding projects on their own time, so it's good to put yourself in situations that force you to do it.
Overall great advice though.
I would caveat this with: Make sure you have some structured activity that forces you to write a bunch of code. If you're not competing in ICPC or doing something similar, you should be taking courses like Operating Systems, Compilers, etc. that require significant coding assignments almost every semester.
Theory classes like Discrete Math, Theory of Computation, Algorithms, etc. are great, but it's important to have structured practice to make sure you're developing your coding skills as well. Most students won't actually complete coding projects on their own time, so it's good to put yourself in situations that force you to do it.
Overall great advice though.
Yes, fully agree. I think getting good at algo/DS is essentially the same as doing ICPC. Personally, the limited amount of time I spent on ICPC has probably had the greatest benefit/cost from college in my life so far.
The best advice I can give you is to try things that your professors aren't telling you to do already, and also to try going one layer deeper into the system then you think you need to in order to solve problems. Doing so will reveal things to you about why the solutions are the way they are.
You'll probably come out with a good understanding of gc'ed languages like Javascript and Python, but the interpreters for these languages still interface with the modern operating system with a systems language like Assembly, C, or Rust.
Maybe try bringing up a simple application on a Z80 or similar MCU that blinks an LED connected to a GPIO. Then switch to using the pulse-width-modulated output to blink the same LED but at different blink rates and potentially even make it fade in and out.
You will learn more about embedded systems from that project than you ever could from messing with Linux on a Raspberry Pi. And everything you learn will give you a better understanding of how computer systems actually work. You will also have to learn more about C and potentially C++ then you ever thought was possible.
You don't need to write an OS from scratch either. You can use something like https://freertos.org/. There's board support for widely-available platforms.
You'll probably come out with a good understanding of gc'ed languages like Javascript and Python, but the interpreters for these languages still interface with the modern operating system with a systems language like Assembly, C, or Rust.
Maybe try bringing up a simple application on a Z80 or similar MCU that blinks an LED connected to a GPIO. Then switch to using the pulse-width-modulated output to blink the same LED but at different blink rates and potentially even make it fade in and out.
You will learn more about embedded systems from that project than you ever could from messing with Linux on a Raspberry Pi. And everything you learn will give you a better understanding of how computer systems actually work. You will also have to learn more about C and potentially C++ then you ever thought was possible.
You don't need to write an OS from scratch either. You can use something like https://freertos.org/. There's board support for widely-available platforms.
Thanks a lot for your advice
Computer science is not software engineering.
They are both very valuable and are extremely complementary but they are not the same thing. As you enter the workforce, understanding this distinction will serve you well.
They are both very valuable and are extremely complementary but they are not the same thing. As you enter the workforce, understanding this distinction will serve you well.
Seconded. And, if you're intending to head for industry (and something like 95% of CS grads wind up there[1]), you need software engineering more than you need CS. Try to get as much of it as you can.
[1]: All numbers made up.
[1]: All numbers made up.
- If you're in it just for the money, bounce now.
- Be curious.
- Push your comfort-zone, often. Do hard things: write a C compiler, design a pipelined/microcoded/branch-predicting MICMAC processor, write a kernel module, write a 3D graphics engine, and so on.
- Master the fundamental concepts, data structures and algorithms.
- Dig deep: computer architecture/organization, assembly, Linux from Scratch, source code of OSes/tools, etc. And, there's more out there than just FOSS; some very useful tools aren't new, OSS or popular. Get proficient at debugging tools.
- Don't get stuck, emotional or religious about any one domain.
- Master one or two domains.
- Be ambivalent, healthily suspicious of and open to "new" flavors of tech fashions.
- Practicing and reading books is all well-and-good, but trying to make something is the best teacher.
- Throwing away and rewriting a few times helps.
- Write for clarity, not cleverness.
- Work on something that matters.
- Avoid job security where you can by documenting and writing obvious code, because it will hold you back more than help.
- Don't write useless, giant comments.
- Don't write heaps of uncommented code.
- Literate programming can be awesome for tricky/complicated desired code behavior.
- Don't reinvent the wheel if you don't have to.
- Premature optimization is a faux pas.
- Small changes.
- The only good code is small pieces of low complexity, tested code; fragile, big function, "black boxes" are evil.
- Use mostly standard conventions.
- Have fun, break things and put them back together again :)
- Be curious.
- Push your comfort-zone, often. Do hard things: write a C compiler, design a pipelined/microcoded/branch-predicting MICMAC processor, write a kernel module, write a 3D graphics engine, and so on.
- Master the fundamental concepts, data structures and algorithms.
- Dig deep: computer architecture/organization, assembly, Linux from Scratch, source code of OSes/tools, etc. And, there's more out there than just FOSS; some very useful tools aren't new, OSS or popular. Get proficient at debugging tools.
- Don't get stuck, emotional or religious about any one domain.
- Master one or two domains.
- Be ambivalent, healthily suspicious of and open to "new" flavors of tech fashions.
- Practicing and reading books is all well-and-good, but trying to make something is the best teacher.
- Throwing away and rewriting a few times helps.
- Write for clarity, not cleverness.
- Work on something that matters.
- Avoid job security where you can by documenting and writing obvious code, because it will hold you back more than help.
- Don't write useless, giant comments.
- Don't write heaps of uncommented code.
- Literate programming can be awesome for tricky/complicated desired code behavior.
- Don't reinvent the wheel if you don't have to.
- Premature optimization is a faux pas.
- Small changes.
- The only good code is small pieces of low complexity, tested code; fragile, big function, "black boxes" are evil.
- Use mostly standard conventions.
- Have fun, break things and put them back together again :)
Do an internship. I found getting experience working with real cow-orkers and (hopefully) dealing with issues that affect real flesh-and-blood customers was incredibly valuable. Make sure you are paid, by the way . . .
Read a ton of code. You're going to be spending your entire career doing this, so you might as well get started.
My personal prejudice is to understand what's going on at all levels of a computer, from the silicon all the way to user experience. You don't need to know the gory details of transistor physics, but knowing in general what's happening at the major levels of things will be an invaluable.
Read a ton of code. You're going to be spending your entire career doing this, so you might as well get started.
My personal prejudice is to understand what's going on at all levels of a computer, from the silicon all the way to user experience. You don't need to know the gory details of transistor physics, but knowing in general what's happening at the major levels of things will be an invaluable.
Regarding internships - they can be very difficult to get. When I was in school, I was at a top school, so everyone was a top student. I was probably average for my school, which meant I could never get an internship because there were always 20 people better than me for any position and everyone applied. Instead, I spent summers working on the University's network which gave me a lot of real-world experience. Unfortunately, most employers didn't find it worthwhile (despite the fact that our network was significantly larger and more heterogenous than theirs), so while it didn't look great on a resume, it actually helped enormously in actually doing the work I eventually got. After my first job, it was easier to find places to hire me because I was "proven." But I really would have liked to have gotten an internship. Nobody was interested in me, though. I hope the OP has better luck (or skill) than me!
In no particular order:
- Find out which courses at your university require lots of coding, and make sure you take those. Often these will be known as some of the hardest courses in the department (although some hard courses are more theory-focused). Those classes will be your most direct preparation for the work you'd be doing if you took a job as a software engineer.
- Identify the smartest/most talented students who are in your classes, and look for opportunities to work with them. You don't necessarily have to be social friends, but you should aim to work on problem sets and group projects with them if possible. When you're working with them do not skimp and let them do all the work - put in the best effort that you can, so that they enjoy working with you. You'll learn a lot from them, and they will be a core part of your professional network after you graduate. Later in your career when you're looking to switch jobs, your former classmates will be happy to endorse you when you apply for a role at their company (and vice versa).
- Office hours are underutilized, and tend to be frequented by students who are asking for extra credit, deadline extensions, etc. For each of your professors, read their web page and skim some of their publications to get an idea of their research area. If the topic interests you, then come up with some questions to ask, go to office hours, and ask them. You will broaden your knowledge of CS, and you never know when something you learned this way might be useful in the future. Learning firsthand from experts in the field is a rare opportunity, and you don't even have to be graded on it. If you're particularly interested in the topic, it's normally pretty easy to get involved in research as an undergrad, since you you cost basically nothing.
- Make sure you take Linear Algebra, because it's really useful for stats, ML, etc. and it's a pain to learn by yourself.
- Don't forget to have fun! Get involved in 1 or 2 on-campus clubs or organizations with people that you enjoy spending time with. This doesn't have to be CS-related - any shared interest works well, whether that's outdoor activities, literature, sports, theater, photography, etc.
- Find out which courses at your university require lots of coding, and make sure you take those. Often these will be known as some of the hardest courses in the department (although some hard courses are more theory-focused). Those classes will be your most direct preparation for the work you'd be doing if you took a job as a software engineer.
- Identify the smartest/most talented students who are in your classes, and look for opportunities to work with them. You don't necessarily have to be social friends, but you should aim to work on problem sets and group projects with them if possible. When you're working with them do not skimp and let them do all the work - put in the best effort that you can, so that they enjoy working with you. You'll learn a lot from them, and they will be a core part of your professional network after you graduate. Later in your career when you're looking to switch jobs, your former classmates will be happy to endorse you when you apply for a role at their company (and vice versa).
- Office hours are underutilized, and tend to be frequented by students who are asking for extra credit, deadline extensions, etc. For each of your professors, read their web page and skim some of their publications to get an idea of their research area. If the topic interests you, then come up with some questions to ask, go to office hours, and ask them. You will broaden your knowledge of CS, and you never know when something you learned this way might be useful in the future. Learning firsthand from experts in the field is a rare opportunity, and you don't even have to be graded on it. If you're particularly interested in the topic, it's normally pretty easy to get involved in research as an undergrad, since you you cost basically nothing.
- Make sure you take Linear Algebra, because it's really useful for stats, ML, etc. and it's a pain to learn by yourself.
- Don't forget to have fun! Get involved in 1 or 2 on-campus clubs or organizations with people that you enjoy spending time with. This doesn't have to be CS-related - any shared interest works well, whether that's outdoor activities, literature, sports, theater, photography, etc.
1. Spend some real time and energy learning how to debug:
https://blog.regehr.org/archives/849
2. Learn how to decompose big problems into a set of little problems. I'm not sure where (if) they teach this in CS but that's the skill that really lets you get somewhere interesting.
3. Find a group of friends and build something together. Most professional programming is a group activity and learning how to communicate and work with other people is super valuable.
2. Learn how to decompose big problems into a set of little problems. I'm not sure where (if) they teach this in CS but that's the skill that really lets you get somewhere interesting.
3. Find a group of friends and build something together. Most professional programming is a group activity and learning how to communicate and work with other people is super valuable.
Build up formal foundations eg. complexity, runtimes, grammars, state machines and proofing (use something like coq to get used to it). Learn an imperative (c), a functional (haskell), a declarative (answer set programming or prolog) and an oop language (java). if you understand them you can easily switch between languages. do math and ignore ai because it's just simple math. Do something with parallel computing eg use MPI, OpenMP or computations on the graphic card. keep coding.
Thank you for answering my question! :-D
Take courses across a breadth of areas in Computer Science, even if you think you don't (or won't) enjoy them much. Don't take up courses only in areas you enjoy (say, Networking) and have no concrete knowledge of areas you think you don't really like (say, Graphics) - Undergrad in my opinion is ideal for building up breadth of Computer Science knowledge. You can always focus on specific areas in grad school or when you start working.
http://paulgraham.com/college.html outlines the advice of pg on the subject.
Practice building things from start to finish. Figuring out how to start and keep intellectual "blinders" on to keep yourself focused and making progress is a really important skill that's hard to develop otherwise.
Go to meetups and well... meet people and potential investors / founders. If you do this you'll have a good set of potential mentors and likely not have issues finding interviews when it's time to look for an internship or job.
Go to meetups and well... meet people and potential investors / founders. If you do this you'll have a good set of potential mentors and likely not have issues finding interviews when it's time to look for an internship or job.
I'd second going to meetups. Students often don't think they belong but most professionals love helping students out.
Thanks a lot for your advice!
No worries! Feel free to PM or reach out if you're in Boston / NYC.
Another tip is to never speak negatively of anyone you've worked with as an intern to other potential employers. Once you're a professional, I'd air on the side of neutral if someone asks why you left a startup or your opinion of a specific ex-colleague.
You never know who you're talking to also knows... Been burned by that one when I thought I was just "being honest".
Another tip is to never speak negatively of anyone you've worked with as an intern to other potential employers. Once you're a professional, I'd air on the side of neutral if someone asks why you left a startup or your opinion of a specific ex-colleague.
You never know who you're talking to also knows... Been burned by that one when I thought I was just "being honest".
One thing that helped me a lot was getting involved in competitive programming. Back then it was just the ACM contests but now there are multiple sites like Topcoder, Codekatas, Codewars, etc. Working through different levels of challenges in different languages helps push your language and algorithm knowledge. Reading other people's solutions is also a huge help.
What kept me from quitting my computer science program was advice I got from a friend of mine:
> A computer science program is like training for the Olympics only to coach your little cousin's softball team
In other words - it's going to be hard, it's likely going to over prepare you for the real world, but if you make it, you'll be fine.
> A computer science program is like training for the Olympics only to coach your little cousin's softball team
In other words - it's going to be hard, it's likely going to over prepare you for the real world, but if you make it, you'll be fine.
You must learn how to learn. You need to be able to teach yourself new things. Professors will only be around for a brief moment, and in the real world you'll need to be able to teach yourself new things from the internet and books. So whatever it is you decide to learn, try and teach it to yourself using available materials.
General workplace advice:
Know how much you want to work. Don't get exploited into doing extra work. Do your best not to take work home. Your boss it typically useful, but ultimately he's not your friend. Keep your dignity and try to have a life outside of work.
Other than that, know what interests you and what doesn't interest you. Don't be afraid to reevaluate your interests over time. Don't be afraid to ask questions. If you think you're correct, be confident and say it.
Some people will say a breadth of skills is important and they are. But don't seek undue skills just because people say they're important. Do what interests you and you'll find a way to make it work out. Though in general, having a base of knowledge in complexity, algo, and data structures will help you find a job quicker. Every computer science program will teach this though.
Other than that, know what interests you and what doesn't interest you. Don't be afraid to reevaluate your interests over time. Don't be afraid to ask questions. If you think you're correct, be confident and say it.
Some people will say a breadth of skills is important and they are. But don't seek undue skills just because people say they're important. Do what interests you and you'll find a way to make it work out. Though in general, having a base of knowledge in complexity, algo, and data structures will help you find a job quicker. Every computer science program will teach this though.
Writing is a highly underrated skill. Start practicing how to write effectively, to be succinct and precise.
Reading helps in more ways than you might imagine - voraciously read.
Build many things. They don't need to be large, they don't need to be fancy.
Reading helps in more ways than you might imagine - voraciously read.
Build many things. They don't need to be large, they don't need to be fancy.
Make sure you understand big-O properly. Focus hard on algos and data structures. Keep looking for areas of specialization, eg Networking, AI, compilers, formal grammars, etc. Don't forget to work on the math. Keep coding.
Thanks for your advice!
Should I learn Data Structures and Algorithms outside of the course ( it is offered in the second semester ) or wait for it to be taught? A lot of students in fact do the first ( competitive programming ) but I personally don't like it.
Pursue what truly interests you, not the hot trends of the day, which will be gone in a year or two.
Fundamentals. Algorithms, efficiency.
Related maths that interest you and intersect with CS. Topology, graph theory, set calculus.
Fundamentals. Algorithms, efficiency.
Related maths that interest you and intersect with CS. Topology, graph theory, set calculus.
Take as many math and/or statistics classes now up to as high a level as you can while still learning effectively.
Learn C and some asm, so you know how the computer really works. There will always be jobs for people who know that. Jobs in the higher levels shift a lot (go find someone today who still gets paid to write visual basic)
Do not incur more than $7,540 in debt. This is half a minimum wage job so even if you can't get employment and have to live with your parents, you can pay it off in max 6 months with just a min wage job.
Learn a lot now about the societal context in which you will practice, decide how you want to fit into the world, and pursue that.
Practice writing, speaking, and presenting. Communication with other people is key to working on projects and teams.
Find a company that's going to grow.
This single factor can dramatically affect your career growth.
This single factor can dramatically affect your career growth.
Get the fuck out of coding. Get an MBA and if you must remain in tech rather than doing productive work: become a product manager. Preferably not in the US.
Being a coder means being a commodity; you're competing with people in countries where the GDP per capita is less than $2k. Unless you can quote chapter and verse from Knuth, and since you're mentioning Javascript, you probably can't, you're human chum to be exploited by oligarchs. Find something better to do, even if it's bullshit.
Being a coder means being a commodity; you're competing with people in countries where the GDP per capita is less than $2k. Unless you can quote chapter and verse from Knuth, and since you're mentioning Javascript, you probably can't, you're human chum to be exploited by oligarchs. Find something better to do, even if it's bullshit.
Ironically this is the exact opposite advice I would give, as someone 3 years out of undergrad with lots of SWE and non-SWE (PM, consultant, banker) friends.
If a college student told me "I want to optimize for a career where I don't feel like a commodity, have lots of bargaining power (high wages, short hours, easy to switch jobs), and can easily start a business or consult on my own if I desire," I'd tell them: study computer science. SWEs I know at the big tech companies are being paid the same as my banker friends for half the hours (or less). The consultants and PMs are working longer hours for half the money and way less job security.
By definition if you're selling your labor on the job market you're being a commodity. I can't predict the future, but for now at least being a SWE seems the best way for a recent graduate to win some bargaining power back.
If a college student told me "I want to optimize for a career where I don't feel like a commodity, have lots of bargaining power (high wages, short hours, easy to switch jobs), and can easily start a business or consult on my own if I desire," I'd tell them: study computer science. SWEs I know at the big tech companies are being paid the same as my banker friends for half the hours (or less). The consultants and PMs are working longer hours for half the money and way less job security.
By definition if you're selling your labor on the job market you're being a commodity. I can't predict the future, but for now at least being a SWE seems the best way for a recent graduate to win some bargaining power back.
This is terrible advice.
No, it's absolutely realistic advice. It's a shitty profession unless you're insanely great at a speciality. Telling kids some nonsense about study X, Y Z is bad advice and cruelty to animals.
We really don't need to breed a new generation of code monkey slaves. You're better off studying watchmaking or leather working if you want a craftsman like profession involving science and engineering. Otherwise: be the boss.
We really don't need to breed a new generation of code monkey slaves. You're better off studying watchmaking or leather working if you want a craftsman like profession involving science and engineering. Otherwise: be the boss.
You're seriously delusional. I've had largely great experiences as a developer and its largely a passion for me still. Sorry it wasnt a free meal ticket for you.
Oh and by and large I'm a generalist.
I did fine; mostly at prediction. Anyone who can't see the writing on the wall is fooling themselves, and telling young people otherwise (aka just study X as a generic javascript dude who studied in collitch) is a terrible, terrible thing.
Schools who sell sugar plum fairies should stake their students success. Are you willing to give this kid advice that you're on the financial hook for for the next 40 years?
Schools who sell sugar plum fairies should stake their students success. Are you willing to give this kid advice that you're on the financial hook for for the next 40 years?
I think there's a recipe for becoming one of the dreaded "code monkeys":
- "Hey, I could make a bunch of easy money writing code!" So, off to school for a degree, not bothering to learn anything other than VM-based languages and web development.
- Get a job and never crack open a book (or read a paper) on software again.
- Only learn new stuff as it pertains to your immediate work.
I see this time after time in the resumes that I encounter. I think the half-life of a software career that follows this pattern is about 15 years and that's probably being generous. These people will spend most of their time either being taught the ropes as an industry newcomer (which is fine) or being told what to do by others (because they didn't keep their skills up). Their agency never really develops because their skills stagnate relative to the people who do get with a program.
I don't mean that someone should work all day then go home and commit like crazy on personal projects, that's also terrible advice. But it's not hard. For instance, if they spend an hour a week reading a conference paper then that's 50 papers a year and they're probably learning new things (or are at least aware of what they don't know); spread the subject matter around and after a few years of this they'll be in conversations like "Hmmm, this feature we want looks a lot like that consensus thingy I read about a few months ago, and they solved it by..."
"Wow, how'd you know about all that stuff?"
Reading a couple papers, maybe an hour or two a week, why?
The G-G-GP is terrible advice because someone who is even a little motivated and who exercises above-average career upkeep can do really, really well and have a long tenure writing software. People will want to work with them, even. Managers will ask their advice on a regular basis! Advising people who are technically inclined that getting an MBA is unconditionally better is just, well, wrong. I could be more forceful.
tl;dr; if you treat your software career like an actual career (and not some kind of easy con on the world that will continue to pay off for decades) then you'll probably get good results.
- "Hey, I could make a bunch of easy money writing code!" So, off to school for a degree, not bothering to learn anything other than VM-based languages and web development.
- Get a job and never crack open a book (or read a paper) on software again.
- Only learn new stuff as it pertains to your immediate work.
I see this time after time in the resumes that I encounter. I think the half-life of a software career that follows this pattern is about 15 years and that's probably being generous. These people will spend most of their time either being taught the ropes as an industry newcomer (which is fine) or being told what to do by others (because they didn't keep their skills up). Their agency never really develops because their skills stagnate relative to the people who do get with a program.
I don't mean that someone should work all day then go home and commit like crazy on personal projects, that's also terrible advice. But it's not hard. For instance, if they spend an hour a week reading a conference paper then that's 50 papers a year and they're probably learning new things (or are at least aware of what they don't know); spread the subject matter around and after a few years of this they'll be in conversations like "Hmmm, this feature we want looks a lot like that consensus thingy I read about a few months ago, and they solved it by..."
"Wow, how'd you know about all that stuff?"
Reading a couple papers, maybe an hour or two a week, why?
The G-G-GP is terrible advice because someone who is even a little motivated and who exercises above-average career upkeep can do really, really well and have a long tenure writing software. People will want to work with them, even. Managers will ask their advice on a regular basis! Advising people who are technically inclined that getting an MBA is unconditionally better is just, well, wrong. I could be more forceful.
tl;dr; if you treat your software career like an actual career (and not some kind of easy con on the world that will continue to pay off for decades) then you'll probably get good results.
:(