this year marks my tenth in tech, regrettably, and i got asked some specific questions that seems like i had useful answers to, so im posting them here.
buckle up, it's long
1. What are some factors that make you feel like a job is worth investing your time/skills into? What are some signs it might be time to leave a job?
This one's already a hard one! When you start out, the first thing that made me feel it's worth it is "making sure I get skilled enough to not get canned". Very quickly after that, it became "you are the sole engineer so get good". I have found that once you have your baseline experience and can navigate the industry more broadly, a single specific job requires two things: a good manager, and an interesting problem space. I often tell people I've stuck around in Data Engineering because of the people, which is very true, but it's not what makes my job feel worth investing in as they are ultimately customers first, and coworkers second. Which is unfortunate, as if I were at a smaller company, that would definitely be the opposite!
2. What sets apart a bad coworker, a good coworker, and a great coworker?
Bad coworker: Undermines your efforts in some way, whether by slowing you down in code reviews by nitpicking, handing off bad things to you, arguing over everything, etc. Generally, bad intent is required here. There are obviously cases where someone is just not prepared to do the job they need to do, and if they're in that position then it's much easier to manage than if someone dislikes you. Similarly, someone who uses you all the time to get their work done without genuine effort from their side is also a bad coworker.
Good coworker: Someone I trust to get the job done, skill-wise. If I'm able to get the job done working with someone, and they are respectful of my time and work, they're probably a good coworker.
Great coworker: Someone I trust both skills-wise and interpersonally. Someone who doesn't take advantage of my time and is instead respectful of it, who works hard to educate others, including myself, on the skills they learn, and just generally does work that lifts everyone up. It's easy to be a great coworker once your skills are squared away, which really only leaves interpersonal and office politics you have to deal with, and if the person makes those easy or at least less stressful when they're involved, then they are definitely a great coworker.
3. What were your original goals with software development? What are the biggest challenges you face working to achieve those goals?
Video games. But, the games industry sucks, so I landed a data engineering job, which turned out to be my jam, and never looked back.
4. How do you keep up with new software and software trends? What parts of your education are most useful to your job? Do you have to do any continued education while working in this field?
Read tech news - Twitter used to be great for this. Engaging tech community is also great - if you find some social spaces where people talk about tech, you are going to get way more exposure than elsewhere. This doesn't mean to seek out people specific to this, but more to go out and meet people interested in the same things as you and then joining or building spaces with them.
As far as education goes, the most useful bits stem from algorithms and data structures. If you can understand how to effectively use maps and lists and some of their associated data structures, you can do a lot more than most other topics. Hilariously, databases was my least favorite class in school, and here I am working daily with databases 10 years later.
Continued education in general really depends on what your focus is. For me, I don't really need to go back to school to do my job well. For other fields that require specific algorithmic or exploratory work, furthering your education through academia can be very useful, not just for learning your skills but for building your network so the problems you are most interested in are ones you can professionally engage people you meet.
That said, even outside of academia you should always make sure you are learning new things, or unlearning bad things. A growth-oriented mindset is really important in this field where the best technology tends to get thrown in disarray every 1-2 years, and being able to adapt and learn how to leverage new strategies and paradigms is very important, so even outside of academia you should always be thinking about how to solve problems in a way more than just "there, I implemented X feature".
5. What steps do you take in creating something new? Is there a formula or routine you go through?
It depends! If I'm working on a very large project that spans multiple quarters and I have a team to rely on, I love to drill in and build design documents to outline the expected behavior of what needs to be implemented. It's very important to understand inputs and outputs with the highest specificity regardless of the context of what you're working in; much of the rest is meaningless in the context of back-end work.
Outside of that, there's a lot of things you have to pay attention to:
- Security
- Speed
- Required infrastructure
- What toolsets you have to work within
- How to ensure the design is able to be engaged without you
Generally speaking my process is a little like this:
a. What techs do I need for this project to be successful? b. What infrastructure do I need for this project to be successful? c. Are there unknowns that I need to be aware of as I work through this? Are there unknowns I can eliminate before I start? d. OK, I've settled on a design and I'm starting to build code. How thoroughly does this need to be tested? What kind of testing needs to be done in an ongoing basis? How can I build this in a way that makes future testing easier? e. As I work on this, are there any security vulnerabilities I can imagine? Once I have a baseline product, I think through the basic tenets of STRIDE and evaluate how what I've built can be exploited to ensure that I understand the risks involved. I usually don't really formally do this, but doing so can help produce some very useful documentation for the team. f. Once I have a proof of concept, I look at what needs to be improved vs. what I want to be improved. Is there tech debt that I've created by building it the way I did? Will that tech debt get in the way of future development? If it's bad enough, I will typically rebuild things to ensure future tech debt is not harder to fix because I continue to work on the project. g. Testing. Once I have a proof of concept, what kind of testing needs to be done? Do we need integration tests? Do we even need unit tests? Do we need some basic walkthrough instructions on testing so there's at least a sanity check on future changes? h. Documentation. What do other team members need to be successful working on this without me? What kind of documentation is needed for end users to be successful? Are there any supplementary design documentation that needs to be more fleshed out now that the design has been implemented? i. Compilation and deployment. What kind of build & deployment process do we need? Are the current ones I used to test this out enough? Do I need to shift to making this run inside of a container? Are there any issues that could come up if we need to change how we deploy or run this? Are there any parts to this that would make future development hard? IE. is local-only testing fine, or do we need some kind of beta environment we can test this in? What kind of infrastructure do we need to do so successfully?
I'm sure I'm missing something here, but this is the best I got for now.
6. What is the biggest mistake that most programmers make when they first start out? How can you avoid these pitfalls? Did you make them?
The biggest is letting the perfect be the enemy of the good. You should be able to rely on your team to help you with early technical problems, and if you can't, you will have to work extra hard to ensure that what you are doing is going to be up to snuff. Figure out the culture of your team and try your best to push people to think critically and respectfully of your code so that you don't have to be perfect in order to be good at your job.
I had problems with this all the time starting out, especially when I become the lone engineer one year in and had nobody with my domain's knowledge to rely on.
Another thing is, don't be afraid to ask your manager for help. Be open with your manager about your situation, and raise any issues that could cause problems beyond yourself up. If your manager really sucks and you can't do that without risk of retribution, this part can be very hard because you have to pick and choose your battles. It's important that you make yourself easy to manage for your boss - if they know what you're doing and what problems you're having closely, it makes it much easier for them to understand how to communicate that to the rest of the business in a way that doesn't fall entirely on you if things go south.
obviously, apply the bad/good/great paradigm here and understand that your boss has power over you in a way that can get you fired, so cover your ass always! paper trails of signoffs, tickets, deliverables, metrics, coworker reviews, etc. You get used to doing it more or less automatically after a while, but it's a skill you HAVE to nurture.
Also, always be friends with IT if you can. They know if you ever look at porn.