In December of 2021 I graduated with a degree in Computer Science. I've been working as a programming contractor for the USGS where I build python applications for them. I wanted to share some of the lessons I learned being in the workforce that aren't taught in school for other new programmers.
1. Don't Overcomplicate Your Code
If you can barely understand how your code works then how do you honestly expect others to? If your code is open source and going to be used by developers with a variety of skill levels make it easy to understand. Making your code will make it easier to maintain by decreasing the amount of time it takes to read your code.
2. Write Down Your Problem Solving Process
"The mind is messy, but paper is clean". When you're struggling to solve a complex problem writing it down takes the pressure of your brain by allowing you to offload your thoughts to the paper. This lets you clearly see the entire problem on one sheet of paper instead of a cluster of messy thoughts. It also makes the problem less intimidating by simplifying it to simple steps.
3. Take Notes on How to Set Up Your Dev Environment
You will forget how you set up your complex dev environment at some point. Use a tool like Notion to create a wiki where you can write down the steps you took to build your dev environment and never forget again.
4. Talk to Other Developers about Your Problems
Whether you are stuck on a problem or just need some inspiration talking with other developers lets you consider solutions and perspectives you would have never thought of. It helps you see the simplest and most effective solution because they aren't biased to the same solutions and mindset you are. Plus its fun!
Check me out on GitHub
I work on open source projects and I'd love to work with you.
https://github.com/2320sharon
Top comments (9)
Number 1 in your list should be covered, at least implicitly, in any good CS1 / CS2 sequence. Although not likely an explicit topic of those courses, feedback given to students on graded programming assignments should include this. How well this is done likely varies wildly.
Anyway, all of your points are good advice.
Maybe, you're thinking about what I'm saying subjectively. Let's keep it simple. And try not to avoid the problem; you think people who make things complex are idiots, that's just negative energy; and preech avoidance of people, which isn't very inclusive. You seem to believe these people exist whether or not they're hypothetical. Last word.
The key to #1 is the "over" in "overcomplicate". In my line of work I see the reverse far more often, a reluctance or refusal to attempt complexity. As a result I see problems going unsolved rather than solved poorly.
The catch though is that I don't have any better way of being able to tell the two apart - the complicated and the over-complicated - than experience.
At the other end is where I agree, that having made a solution which is complicated, the next task is to attempt to reduce it to something less complex. I'd even suggest that step is more important than the documenting, because usually the person who crafted the complexity is well placed to know which parts proved to not be needed. On reflection that's perhaps the ideal point to bring in someone else, as a pair programmer, to help prune the code deadwood.
Or maybe someone inexperienced at programming, we don't need harsh language when we want to help build these people up.
Like using React to build a small, single page portfolio site that has almost no interactivity?
Just sounds like those people need guidance, rather than being avoided. "LOL". Your advice sounds toxic.
3 should be in the projects readme, and if it's not, or its out of date, makes for a fantastic first pull request.
Uh huh nice spin, you're still calling people idiots.
Great tips!
Number 2 is something I do often. And number 3 has saved me a lot of time.