Software Engineering is like being a maestro and putting pieces into places that need to be. I’m writing this article based on my everyday experiences as a software engineer. I want to share what I find to be the most difficult parts of the field.
I’m aware that others may have different ideas about the challenges of being an engineer. I hope we can open a discussion for others to chime in.
Systems Design
Systems Design is about designing an architecture for your software application. However, it can also be one of the things that turns out to be the trickiest. There are many moving parts and entire books dedicated to different design types.
What’s always tricky about designing your system is that you need to think of the frameworks, technologies, processes, and business needs.
There typically isn’t a one-size-fits-all solution to systems design, you’re forced to do your research and if you aren’t used to building from scratch this can be the toughest place to start.
Coordination
Coordination goes hand-in-hand with systems design, but it involves the overall aspect of engineering. Thinking about what makes software engineering challenging is that you often need to communicate, organize, and list out objectives with specific deadlines.
Even with deadlines, it’s hard to predict what can come up. If a coworker is out of town, you lose an extra hand on the workload. If a bug that you once thought would be very simple to handle, is turning out to be a two-week headache you’ve just wasted time.
Many resources mention coordinating projects and sharing deadlines with longer durations. Most likely to create padding in case of moments just like the bug example.
It’s important to look at all aspects of your project and determine when things should happen and when they shouldn’t.
Time Management
About coordination, comes time management. Managing time is often another difficult part of software engineering. You swear you can do a feature or bug fix in x amount of time. Only to find that x amount of time has increased and you need to adjust the timeframe.
If we were managing time for solo projects, it might not be a concern. However, trying to state to your bosses why something is taking longer than it should can feel embarrassing.
I know I felt truly embarrassed and ashamed thinking the item I worked on was easy and achievable turned out to be the opposite.
I learned as a result of the coordination step that padding time helps, but if you can deliver earlier you should.
Also, using tools to keep track of time spent like JIRA is typically used by your employer, it may seem like a bad thing and honestly, I sometimes dislike feeling pressure via time to deliver.
However, It helps to analyze how much time I’m spending and if I can’t move to another task or look for better answers to speed up the process.
Documentation
This seems trivial, why would documenting our work be difficult? In part because of time constraints, requirements, and policies by our bosses. Agile software development is all about moving along quickly. Jump from task to task, don’t stagger behind.
Documenting is that however after we moved so quickly. We want to slow down and prepare the next generation of engineers with materials that would help them get started.
I believe it’s counterintuitive not to enforce documentation, while it may slow down your ability to jump to a new task. In the long term, you save your organization precious time that can not be retrieved.
If another engineer has to read through our code line by line to get a grasp.
If documentation isn’t allowed or it’s bare. I suggest trying to write your code like a piece of documentation. Make it easy to read, variables should make sense, functions should operate as expected; nothing more, nothing less.
Have a top-to-bottom reading approach. Your code is your message to another engineer, not just a tool to get an app working. Read why I think documentation is important: https://draginto.com/opinion/why-documenting-work-is-so-important-as-a-software-engineer/
Hard Skills in Software Engineering
The difference between hard skills and soft skills is noteworthy. One is about studying the more technical issues involved in software engineering and the other is about how to manage, communicate, and how to engage with other humans.
Soft skills can be challenging to learn, however I find there is a constant in the learning required. For soft skills it’s typical to follow the same pattern to get better. With hard skills however, I feel there is constant novelty. Some new tech, tool, or resource requires us to read about and study the material.
Learning technical skills can be especially difficult due to new concepts needed to learn and time constraints.
Here’s just a sample list of just how big your learning can be with hard skills: AWS, React, Vue, Redis, MongoDB, PostgresSQL, PHP, MYSQL, Javascript, Typescript, UML design, Object-oriented programming, Algorithms and Data structures.
Want to Learn about Vue.js read my blog post on why I think its great: https://draginto.com/computer-science/why-i-think-vue-js-is-great/
Standing Out From the Crowd
When looking for the next promotion the biggest challenge for yourself should be how you can stand out from the crowd. There will be many engineers around you, each with their special abilities.
What I think is difficult about working for a business, is how to get that business and its members to notice you. There is no “right” answer to this. For me, it comes down to how well you communicate, how you complete tasks, and most importantly, how well you know your higher-ups.
Networking and building relationships don’t sound like an interesting part of engineering, but it’s the only method by which you can advance in your career and work on other things that might interest you.
It’s not all bad, however, building valuable relationships can boost your learning as you walk the paths crossed by others. We learn via the experiences had by others. I think that’s an extremely beneficial part. This is also a soft skill that can be the best to get better at.
Creativity
Being creative is a great trait to have as a software engineer and I think it’s actually quite fundamental to how we approach designing our applications. Being creative is hard, it’s hard to create something out of thin air and then build upon it.
There are many ways to be creative in the process, one for example is needing to design an application that runs a specific hardware that has limitations.
What should you do with your software then in that moment? What are ways could you tackle the limitations and create things that seem “limitless?”
Limits are always something we as engineers need to have a grasp on, because they tell us how we need to optimize, shift or rethink our apps across-the-board to give our users a better experience.
I like to think I can be pretty creative, but I’ll be honest the “aha!” moment doesn’t come right away. I often have to leave my brain processing the thoughts behind the scenes while I do other tasks.
Eventually I find some super nifty way to do something and its always those moments that offer the highest gratification.
Being creative is about playing with art (your code) and creating something that your users will love.
If you ever want to see how some game developers were able to deal with hardware limitations for their software check out this interesting video:
