20 votes

What helped you succeed or improve in your field?

As an undergrad computer science student, I'll be starting my career soon. I want to make it enjoyable, productive, avoid too many mistakes and generally try to succeed.

If you want to share anything that could be beneficial to succeeding in various tech fields, either books, advice or really anything else - I'd like to hear it.

Books
Are there any books that you can recommend, which helped you in your career. From hard technical skills, to soft interpersonal skills required to succeed in software engineering, systems engineering, or similar fields. Books oriented towards problem solving, algorithms, good engineering practices, etc.

A book I found recommended quite a lot, but didn't get around to reading just yet is Designing Data-Intensive Applications.

Blogs or any other sources are welcome as well.

A bit of background

I'm currently an undergrad computer science student, but I started programming around 8 years ago and finished a few projects on my own. I've been working at a small software company for the past 2 years, but I don't really feel like I'm improving as much as I could - mostly due to constrained budgets and short deadlines, which don't allow me to grow. I want to read and improve my skills on my own time as well.

I'm not sure if this topic has been discussed before - I'm new to Tildes and haven't figured out how to filter results to only display topics in ~comp.

26 comments

  1. [6]
    Emerald_Knight
    Link
    There are a lot of things I've learned in the two short years I've been out of college and out in the workplace. Here's a non-comprehensive list: Be willing to scrap days of work and start over...

    There are a lot of things I've learned in the two short years I've been out of college and out in the workplace. Here's a non-comprehensive list:

    • Be willing to scrap days of work and start over fresh. You're going to run into problems where your initial approach turns out to be complete shit. That approach is a mistake. Don't cling to a mistake just because you spent a lot of time making it. Throw it away and start over. You'll thank yourself months down the road when you inevitably have to come back to it and don't have to face that monstrosity you rightly tossed into the incinerator.
    • Never, ever, ever run direct database queries on production without a damned good reason and extensive review and validation that your query isn't going to royally fuck things up. Better yet, write up a script or some other tool to help bake safety into the process. I've had a few close calls with this, luckily catching myself before the stupid could manifest in the form of data loss. Just save yourself the trouble of possibly having to go up to your boss to say "production is down because I destroyed customer data". Seriously.
    • Get used to the concept of technical debt. Any project of sufficient size and age will become more and more difficult to make changes to without either screwing up some other part of the system or needing to untangle a mess of code to figure out which parts you need to change. Learn to watch out for things that "feel" wrong. That's typically a sign of a "code smell", which is a large part of technical debt.
    • Learn to balance productivity in the form of implementing features, and productivity in the form of paying down technical debt. Both are important. Too little focus on paying down technical debt will cause your feature development to grind to a halt, and too much focus on paying down technical debt will likewise cause your feature development to grind to a halt. Make improvements as needed, accept that things aren't going to be perfect, and resume feature development as soon as the major development bottleneck has been eliminated.
    • Learn to love automated testing. For a brand new project, tests will probably only add an additional bottleneck that will prevent you from meeting critical deadlines, but for projects that have grown sufficiently, they will help you make changes quickly and safely by allowing you to validate that nothing was broken. I can't overstate the value in being able to run a script like ./run_tests.sh and have a test suite report back to you which of your test cases are failing and why.
    • If you don't read documentation already, get comfortable with it now. A lot of people on StackOverflow are fucking stupid and will give you an answer that technically works but is so profoundly stupid that I would slap you with a printout of the Linux kernel just to beat some runtime sense into you. Don't blindly copy-paste and modify answers until something works, because that's how you piss off every single one of your successors who have to deal with your shit when you're gone. Read the fucking manual. Figure out why you're writing the code you're writing and what kinds of unintended side-effects might be introduced as a result. Figure out if there's a better or officially recommended solution to the problem, because maybe (i.e. likely) you don't understand the subtle nuances of how the particular technology you're working with gets its job done.
    • Always question your solutions, the solutions of your co-workers, and the solutions of your predecessors. Humans are idiots. We can be certified geniuses and still do stupid shit frequently. I've written code, looked it over several times, released it, and discovered vulnerabilities after the fact, because I don't take my code for granted. You're going to fuck up like that, too. Anticipate it, watch out for it, and fix your fuck-ups when you notice them.
    • Learn to pick your battles. Yes, your database driver has a significant bug that isn't fixed until a later version. Yes, it requires a major language version update. Yes, things will break as a result and many changes to the code will be needed. No, the company doesn't have the budget for it and there are more pressing items that need attending to. No, they're not going to budge on the point. You brought it up to them and they put the ticket in their system, so you've done all you can. It's okay for their software to screw up--it's their software, not yours. Just do what you can to make the parts you work on as good as you can and take pride in what you manage to accomplish.
    • Write scripts. Write lots of scripts. Seriously. I can't even begin to tell you how nice it is to have lots of bash aliases that take care of otherwise lengthy and annoying commands, or shell scripts that accept literally one argument and take care of an entire environment setup without me having to do anything. I can even go get a cup of coffee while my scripts do all of the work for me. If there's anything you use and reuse fairly frequently, write a script for it. If there's anything you use every now and then but not frequently enough to remember, write a script for it. If there are some commands you run every now and then and they're prone to errors if you're not careful, write a fucking script for it. Automate the human element out of the picture as much as possible and next thing you know you'll be wondering why the hell you didn't do that in the first place.
    • Get a password manager. You're going to have lots of work-related accounts to deal with and you sure as shit don't want to reuse passwords for this. If someone breaks in, they can do a ton of damage. So get a password manager, have a work profile, and secure it with 2FA. Then generate secure, random passwords for your work-related accounts. If you're on Linux and like to work with the command line, you might consider LastPass and installing the LastPass CLI.
    • Learn to stop working. No, seriously. Sometimes you'll get tunnel vision and even rubber duck debugging won't help worth a damn. When that happens, just walk away from your monitor. Talk to someone about something not related to your task, maybe about that movie you saw the other day. Go for a walk and get some fresh air. It's not uncommon to bang your head against a problem for hours to no avail, then think of the solution as soon as you're away from your workstation for a good 10-15 minutes.
    • Learn to love whiteboards. A diagram of your program logic can help you identify identical branches of logic and branches of execution that hit dead ends, and you can use those insights to reduce the redundancy and complexity of your code. If you design the diagram as a directed graph, you can also regroup nodes atomically and possibly even reorder them in order to define better functions and methods than what already exist. It's also an invaluable tool for visualizing the propagation and transformation of data throughout your application. And let's face it, our brains have fairly limited RAM available to them, so sometimes we need to write our thoughts to physical storage somewhere so we don't forget anything critical.
    • Impostor syndrome is common among professionals everywhere. You're going to see the intern fresh out of high school having no trouble whatsoever keeping up with you and part of you is probably going to be wondering if you even really know what you're doing because it's looking like he'll surpass you in no time. You'll have to learn not to measure yourself against your peers, and to instead measure yourself against your past self.
    • Your work isn't your life. Don't burn yourself out. Take time for yourself. Exercise, eat good food, have a hobby or two, just do something that isn't related to your work in any way. You're not less important than your work, so take care of yourself.

    I'm sure I'm forgetting a lot of things, but hey, it's a start :)

    27 votes
    1. [3]
      teaearlgraycold
      Link Parent
      To add on to this, whatever query you end up running should be copy-pasted into your ticket. If the fuck up is subtle you want a paper trail of what was done.

      Never, ever, ever run direct database queries on production without a damned good reason

      To add on to this, whatever query you end up running should be copy-pasted into your ticket. If the fuck up is subtle you want a paper trail of what was done.

      9 votes
      1. somewaffles
        Link Parent
        To this point, write everything in a transaction that can be rolled back. I've seen too many people fat finger something, see "100k Records Affected" and the life drain out of their face. I...

        To this point, write everything in a transaction that can be rolled back. I've seen too many people fat finger something, see "100k Records Affected" and the life drain out of their face. I watched one of my first managers delete half a million customer phone records (we had back ups, but was still stressful.)

        6 votes
      2. Emerald_Knight
        Link Parent
        Excellent point! I'm definitely making a mental note of this for myself for the future :)

        Excellent point! I'm definitely making a mental note of this for myself for the future :)

        3 votes
    2. [2]
      eagle
      Link Parent
      That's a lot of really great advice. Although I follow and promote most of the things you mentioned at work, one of the most difficult things about transitioning from freelancing to being an...

      That's a lot of really great advice. Although I follow and promote most of the things you mentioned at work, one of the most difficult things about transitioning from freelancing to being an employee, was learning to pick my battles, like you said. Sometimes choices are not based on facts and technical debt is a bitch.

      3 votes
      1. Emerald_Knight
        Link Parent
        Oh man, I imagine that transition had to be rough. The sudden introduction of rigid structure, development priorities that probably differ greatly from what you would normally set for yourself,...

        Oh man, I imagine that transition had to be rough. The sudden introduction of rigid structure, development priorities that probably differ greatly from what you would normally set for yourself, likely going from starting projects from scratch to maintaining existing projects, having potentially multiple people to answer to instead of just a client... I'm getting flashbacks to my first day working at my internship!

        2 votes
  2. [7]
    cptcobalt
    Link
    I have one bit of advice that I feel should work for everybody, computer science or not: obsessively make to-do lists, every day. Handwritten, not anything in an app. My strategy is pretty much...

    I have one bit of advice that I feel should work for everybody, computer science or not: obsessively make to-do lists, every day. Handwritten, not anything in an app.

    My strategy is pretty much this:

    • A new page for each day.
    • Pre-name your P1 item for the day, at the start of the day. It must get done today.
    • If you do something not on your list that takes a reasonable portion of your time, retroactively add it to your list and cross it off.
    • If you complete an item check it (or cross it with a thin hairline). You might want to read it later (this helps professionally, for self reviews, particularly that P1 field.)
    • If an item doesn't get completed, add it to tomorrow.
    • When writing your list that morning, flip back a few days, and find anything you left behind that still needs attention.
    • (Pro-strat:) Your to-do list items should be discrete, un-blocked, next required actions only. If you are blocked, or it's part of a major project, use another resource (app, another to-do list page, etc) to track that, so your daily lists remain uncluttered and focused, and everything you can do right now.

    Even though I have project/bug trackers at my disposal, adopting a personal daily to-do list in my workflow is, for me, the one thing that gave my career new direction and momentum, and crossing items as you complete them gives you an actual psychological reward. With to-do lists, I feel that I'm better able to keep to personal ideals and direction, rather just deal with things as they hit me.

    (And the fun part: I use Field Notes as my exclusive notebook of choice. Their special editions are always awesome.)

    11 votes
    1. emdash
      Link Parent
      I just started using Field Notes myself in a similar manner (but also included personal todos and self-improvement tasks), and it's been a big boon to my productivity levels across the board. Apps...

      I just started using Field Notes myself in a similar manner (but also included personal todos and self-improvement tasks), and it's been a big boon to my productivity levels across the board. Apps just don't cut it, and you don't get the same level of satisfaction as you do with pen and paper.

      5 votes
    2. eagle
      Link Parent
      I'm definitely going to start writing things down on paper, I agree that using apps doesn't have the same effect. I can be forgetful and lose focus at times, so having it all in one place should...

      I'm definitely going to start writing things down on paper, I agree that using apps doesn't have the same effect. I can be forgetful and lose focus at times, so having it all in one place should help. Especially with assigned tasks being split between issue tracker, Slack and in-person meetings.

      2 votes
    3. [4]
      madjo
      Link Parent
      I got here through your comment on the products discussion. I don't understand your pro-strategy point. What do you mean with un-blocked? And I'm also not sure what 'discrete' means in this context.

      I got here through your comment on the products discussion.

      I don't understand your pro-strategy point. What do you mean with un-blocked?
      And I'm also not sure what 'discrete' means in this context.

      1 vote
      1. [3]
        cptcobalt
        Link Parent
        Yeah, good question! Basically, every item on your to-do list should be the immediate next thing (or lists of "next things") that you need to do, for anything. Unblocked would mean, you're not...

        Yeah, good question! Basically, every item on your to-do list should be the immediate next thing (or lists of "next things") that you need to do, for anything. Unblocked would mean, you're not waiting on someone else to do something before you can get to it, or you need to set up a development environment, or etc. I mean discrete in this context to mean that your list should be separate and distinct: you're not writing down a list of projects, you're writing down separate and individually actionable tasks which help you succeed at projects you've planned elsewhere.

        2 votes
        1. [2]
          madjo
          Link Parent
          Thanks for the clarification. Do you use a specific system to keep track of the status of the todo items?

          Thanks for the clarification. Do you use a specific system to keep track of the status of the todo items?

          1 vote
          1. cptcobalt
            Link Parent
            Not really. I used to use some formal GTD methods, but could never find an app or process that worked exactly for me, and really the biggest boon to my productivity is deliberately planning my day...

            Not really. I used to use some formal GTD methods, but could never find an app or process that worked exactly for me, and really the biggest boon to my productivity is deliberately planning my day at the start of my day.

            A minor chunk of my to-do items are tied to something like a bug tracking system, so I'll often handwrite the bug IDs on the list too. But mostly I just flip back a few pages to canvass for unresolved items (that are still important enough), and float them to today's page. Beyond that, I still try to get most things on the list done that day—often it's like "reply to this email", where it's just silly to add it to some formalized tracker.

            I, sadly, don't have a good enough "future" list. If I'm planning a project I'm leading myself, I tend to use the notes app on my computer and braindump ideas, which then graduates to a few pages of a big notebook as I plan out implementation/workflows/tasks/etc, and then from there it becomes entries in the bug tracker or daily tasks.

            1 vote
  3. [5]
    Deimos
    Link
    Here was a pretty good thread on this topic from a few months ago. I was going to copy-paste my comment from it, but you might as well just check out the whole original thread (keeping this one up...

    Here was a pretty good thread on this topic from a few months ago. I was going to copy-paste my comment from it, but you might as well just check out the whole original thread (keeping this one up is fine too, I just wanted to link to it): https://tildes.net/~comp/6cx/advice_for_those_who_want_a_computer_science_career

    6 votes
    1. [3]
      Kelsier
      Link Parent
      Hi, can I ask you a question? I am about to complete my graduation and already have a job but I have a lot of free time in between and was thinking about brushing up my skills. I am already...

      Hi, can I ask you a question? I am about to complete my graduation and already have a job but I have a lot of free time in between and was thinking about brushing up my skills. I am already familiar with algorithms and data structures but don't have much practice implementing them.
      On the other hand, I am working part time with a startup as a junior developer and learning all these technologies and frameworks which are being used.
      So I guess my question is, what would be a better utilisation of my time (from a career perspective) - learning more about these core concepts in detail or making projects to build my portfolio?
      Sorry if this is a silly question, it's just that I can't make up my mind and am wasting so much time.

      6 votes
      1. Deimos
        Link Parent
        In my opinion, build a project. Not even necessarily for portfolio-building purposes, just pick something you're interested in and try to build a fully usable program/app/site/whatever for it. It...

        In my opinion, build a project. Not even necessarily for portfolio-building purposes, just pick something you're interested in and try to build a fully usable program/app/site/whatever for it. It doesn't need to be anything serious, it can be related to one of your hobbies, tracking scores for a video game you play, whatever.

        I think that's the best way to learn, and by having it be related to something that you're interested in and want to use yourself, that should keep you more motivated to keep working on it. Implementing random algorithms and data structures is fine, but unless you end up working in a very specific type of job, it's not the sort of thing you'll ever need to do outside of interviews.

        6 votes
      2. minimaltyp0s
        Link Parent
        I'd second the vote for building a project. All the theory in the world is nice and all, but without it starting to mean something practical to you then you risk it not sticking in your memory. If...

        I'd second the vote for building a project.

        All the theory in the world is nice and all, but without it starting to mean something practical to you then you risk it not sticking in your memory. If your project hits a stumbling block and you require some theory to get over it then that's real learning that will stick with you.

        In addition, if you consider outsiders looking in (maybe not right now, but future potential employers), then being able to talk passionately about a handful of projects you've built that solve a problem for you will set you apart from someone who can list a dozen esoteric books with interesting theories.

        3 votes
    2. eagle
      Link Parent
      Thanks, there's some good advice there already.

      Thanks, there's some good advice there already.

      1 vote
  4. [5]
    nic
    Link
    There are two paths you could take. If you are interested in eventually moving into management, I suggest you start to focus on a couple of things. Start with who & why. Who is the customer, who...

    There are two paths you could take.

    If you are interested in eventually moving into management, I suggest you start to focus on a couple of things.

    1. Start with who & why. Who is the customer, who is the user and why do they want this. If the answer lacks detailed specifics, you need to get involved with actual discussions with actual users & customers. Keep in mind the customer is almost never the direct user.

    2. Take any opportunity to present. Really dedicate some time thinking about what you will say. Practice. Present. Ask for feedback. Get better at it.

    3. Always say yes. Offer to help out even if it does not directly benefit you. Make your boss look good. Grow your network.

    I presume you have read the lean startup and all the other usual basics.

    2 votes
    1. [4]
      eagle
      Link Parent
      I agree with most of what you've said, but I'm assuming that you don't mean "Always say yes" in absolute terms? I always do my best and try to go above and beyond, but sometimes it just bites you...

      I agree with most of what you've said, but I'm assuming that you don't mean "Always say yes" in absolute terms? I always do my best and try to go above and beyond, but sometimes it just bites you in the ass.
      What if it's working overtime for n-th time due to poor planning? Being asked to deliver something top priority in a timeframe that's not achievable?

      I presume you have read the lean startup and all the other usual basics.

      I haven't, I would actually appreciate a list if you have one.

      1 vote
      1. [3]
        nic
        Link Parent
        Have you already had a frank conversation with your boss regarding unrealistic timeframes? Here are my favorite books, they are all classics Positioning - The battle for your mind The Innovator's...

        Have you already had a frank conversation with your boss regarding unrealistic timeframes?

        Here are my favorite books, they are all classics

        1. Positioning - The battle for your mind
        2. The Innovator's Dilemma
        3. The Lean Startup
        4. The Seven Habits of Highly Effective People
        5. How to Win Friends and Influence People
        2 votes
        1. [2]
          eagle
          Link Parent
          Yeah, we all have. It keeps happening though. Thanks for the list!

          Yeah, we all have. It keeps happening though.

          Thanks for the list!

          1 vote
          1. nic
            Link Parent
            Have you offered to help with t-shirt sizing? Have you suggested taking an agile approach to slicing up user stories? You are astute in your observation that I don't say yes to everything. I say...

            Have you offered to help with t-shirt sizing?

            Have you suggested taking an agile approach to slicing up user stories?

            You are astute in your observation that I don't say yes to everything. I say yes to interesting new challenges. I say no when something is not a good fit.

            1 vote
  5. minimaltyp0s
    Link
    I stopped "learning" and started "doing". I started attempting to break some machines from Vulnhub.com. It was really hard, even though I'd spent a long time reading about the theory. But once I'd...
    1. I stopped "learning" and started "doing".

    I started attempting to break some machines from Vulnhub.com. It was really hard, even though I'd spent a long time reading about the theory. But once I'd started actually applying it, it started to form a natural process for me and I started to build an intuition on what to try, what to focus on, what to leave alone for now.

    1. Started writing about it

    I started writing up the hacks I'd completed. This was intended originally as a means of helping me remember what I'd done but eventually I started to get readers in small-but-ok numbers. And then they started asking questions, which meant I started trying to solve other problems as part of running the blog. I became a teacher of sorts in my little microcosm and that forced me to research the things I was talking about in even more depth since I didn't want to come across like a shill or start giving people bum advice.

    2 votes
  6. Staross
    Link
    If your job doesn't provide you learning opportunities you have to take them yourself, take a few hours during your work to work on personal projects or better contribute to open source projects.

    If your job doesn't provide you learning opportunities you have to take them yourself, take a few hours during your work to work on personal projects or better contribute to open source projects.

    2 votes
  7. lazer
    Link
    I am self taught, so for me it was always learning and having hobby projects going in my spare time. The other thing would be applying for jobs even if I did not tick every single point in the job...

    I am self taught, so for me it was always learning and having hobby projects going in my spare time. The other thing would be applying for jobs even if I did not tick every single point in the job description.

    1 vote