This article was originally published on the Offerzen Blog.
Nine months ago, I was working as a civil engineer and had a scholarship to complete a Ph.D. in chemical and environmental engineering. Today, I’m a geographic information systems (GIS) software developer. Interestingly, I have found that I can apply a lot of what I learned as an engineer to my new role. Here are my four key takeaways from my time as an engineer that have given me an edge in the software development world.
Context
For as long as I can remember, I have loved computers and coding. I taught myself to code in VB6 when I was 14 and I’ve loved it ever since. For one reason or another, though, I didn’t choose that route when I got to university and ended up studying to become a civil engineer.
When I graduated, I started working as an engineer but my passion for computers was still there. Choosing to work with GIS as a civil engineer allowed me to have a very high interaction with computers and, in my free time, I was putting in the effort to further build my knowledge as a software developer. I used a lot of online resources and even took on a few freelance projects to practice my skills and gain experience. It became clearer and clearer that working with computers was what I really wanted to do.
In the last few months, I decided to leave my job as an engineer to turn my passion into a career. While I am really enjoying development, there are a lot of aspects of engineering that I still care about, and from which I have learned a lot of valuable lessons.
Making the shift, I realized that those lessons opened my eyes to a lot of what I was experiencing as a new developer. I’ve found that being aware of certain things has given me a unique perspective and really helped me grow in my new role. Here is what they are.
You should always be open to learning
A good engineer never stops learning
A lot of engineering is based on a foundational science, with certain standards in place that help engineers streamline the application of that science. Despite this, it is still a pretty creative field in that one constantly encounters new problems that push you to think about the established science and standards in new ways.
Engineers need to think about how to challenge what is existing in order to achieve greater efficiency.
This creates the need for continuous learning to keep abreast with changes in the practice.
For example, I was once involved in a water demand management study where we had to develop a strategy for reducing water demand and improving conservation. One of our key discoveries was that the demand management strategy that was in use at the time was based on a study that was done more than two decades before. Because it was working - albeit inefficiently - no one had bothered to update it since it was put in place. So much research had been done in the field that there were many opportunities to reduce the demand quite significantly from water loss in the system. This meant that because those responsible had not continuously learned and applied the advances in the field, each year the utility was losing huge amounts of revenue.
It, therefore, became clear to me that without a firm understanding of the advances, it is difficult to confidently develop solutions to challenges that emerge on a regular basis.
A good developer keeps learning and learns faster
I quickly saw that development is pretty similar in that there is also an underlying science, as well as standards applied to the technologies and frameworks. However, software development changes much faster, which means that older ideas and methods also become obsolete faster. As a developer, you have to keep learning in order to stay relevant. If you slack, your prized skill can become outdated pretty fast.
Software developers are always aiming at a moving target and that is part of what makes it exciting.
As a developer, I experience this quite regularly. The bulk of my work currently involves writing scripts for GIS processing using Python. I have developed some custom modules that a lot of my toolsets refer to for various tasks. Each time there’s a new problem that I need to write a tool for, I do some research for it. While researching for that tool, I usually learn so much that I need to go back to the tools I’ve worked on before to apply my new-found knowledge to them so that they can work better. As a result, my tools are continuously improving because I am continuously learning.
How this has influenced me as a software developer
I have learned from my experience that you should never be satisfied with what you know.
- I always seek to learn more and to expand my capabilities, even if I am tackling the same old problem all the time.
- I make the effort to read further. I have found that learning something new can widen my perspective and give me a better vantage point, which reveals aspects that I previously could not see.
Learning is a gradual process - you need to take steps to get there
A good engineer should demonstrate that they know how to do the job before they start.
Engineers generally need to figure out, to a high level of detail, how each project will be completed before beginning the task. Yes, there is room for some learning along the way but all of that occurs within a narrow deviation from the plan.
This is important because in most cases there is a lot at stake, including people’s lives and considerably high amounts of public funds. Mistakes are significantly difficult and costly to correct. Therefore, stakeholders want to know whether or not the engineers they are working with can design and construct a sewage treatment plant that will live for 50 years before they allow them to use their money. While engineers have a bit of wiggle room, clients want to know, again to a high level of detail, exactly how they intend to build that plant. They need to know that the engineers have all the requisite knowledge before they allow them to take up the task.
A good developer, by contrast, should get comfortable with learning on the job
Software development works a little differently: It allows for much wider wiggle room. Unlike engineering, where clients want to be sure your practical skillset is solid before signing a contract, in development, they usually want to know whether you have what it takes to figure out what it takes.
Because I was used to having to prove the plan from the get-go as an engineer, this mindset shift was difficult. However, it became clear over time that as a developer, I didn’t need to prove a plan, I needed to prove myself. The plan, after all, would probably mutate along the way.
The first time I wrote a geoprocessing Python script, I had accepted the project without any knowledge of geoprocessing libraries. I had used Python before, though never for any GIS work. I took it up because I understood that the knowledge I had was a good enough starting point, and I had enough time to learn the skills I needed. After burning through some documentation and tutorials, I found a way to start and acquired the rest of the knowledge as it became necessary.
What counts is trusting in your general ability. If you can get started, then you can take the next steps to strengthen your understanding of unfamiliar topics as you go.
How this influenced me as a software developer
While research is important, I’ve learned that you shouldn’t get stuck on it.
- I have started letting the requirements of a project direct my learning. I break down the project work into what I do know and start with that.
- I research the parts that I don’t know as I get to them so that I can keep moving. I try to remember that some world-changing solutions have been born from such task-driven learning approaches.
- I remind myself that I don’t always need to know how to do every single thing that needs to be done. To this day, the tasks that I encounter on the go are what directs my learning. If I had backed out because I didn’t understand all the corners of what was needed, I would probably still be trying to gain the knowledge that would make me feel confident enough to start.
It takes time and commitment to get it right
A good engineer meets the full requirements on the first attempt
When tasked with building a bridge, an engineer needs to design and construct a bridge that is complete and works the way it should the first time. During planning, engineers go through the possibilities, consider the options and come to a final solution.
When engineers design and build, they are working on the final product.
That’s why engineering projects often adopt the waterfall approach to project management: Each step of the process is done to completion before moving on to the next step.
Where redoing something does become necessary, it usually comes at a very high cost. This means that often engineers want to build the final solution the first time around and not have to come back to it for a few decades. Best case scenario, they only have to come back to it for demolition, which has already been factored in during the initial implementation process.
A good developer, however, embraces the fact that they will learn as they go
Development works differently: In a lot of cases, neither the developer nor the client has a very clear picture of what the final product will look like. In most cases, all that is needed is a partially working prototype to understand what to add and what to remove.
Therefore, development often takes a cyclical approach to project management where, during each cycle, we produce a working solution to the best of our abilities, knowledge, and resources at that time. Using that solution, we learn, adapt and use that knowledge for the next cycle to improve the product. This means that it is entirely acceptable to have a product that is never fully done.
In other words, it is never complete but it is always complete for that cycle.
Usually, when the GIS technicians present a problem to me, no one really understands what the solution should look like: All we try to focus on is having a very good understanding of the problem. I used to spend hours trying to figure out the solution until, because of time, I would be forced to just start.
Over time, I have realized that after reaching a first version of the solution, I have gained so much insight into how the final version should function that I can work much faster. I’ve found that my eyes are opened to potential possibilities and pitfalls as I go, which has proved to be more useful than spending time trying to figure them out before building anything.
How this influenced me as a software developer
Most importantly, I have realized that as a developer, you shouldn’t get stuck on the details.
- I have started focusing on having a partially working whole to help prioritize the details that need the most attention. I have accepted that sometimes I need to see how something breaks to understand how to make sure it doesn’t break again.
To stay in the game, you have to stay on your toes
A good engineer works around the fact that change happens relatively slowly in this field
It’s not uncommon in engineering for problems to mutate at a rate that is faster than solutions are developed. Innovation simply doesn’t occur fast enough, and, even in cases where a lot of money is invested in research to keep the pace of innovation high, those innovations are not adopted fast enough.
For example, while the technology used to treat wastewater has remained largely the same for over a century, the composition of the wastewater being treated has changed drastically in that period. This has caused a lot of problems for the environment and we are now forced to react, a reaction that is many years overdue.
The cause of all this is that huge infrastructure networks lead to natural monopolies, where it becomes more cost-effective to have one player rather than multiple. Unfortunately, this has also meant that that one player has no competition and, therefore, little incentive to innovate. Thus, wastewater utilities have had little to nothing pushing them to innovate. As long as the environment is able to take the effluent, there is no reason to make changes.
A good developer, by contrast, works to keep up with rapid innovation
Because aggressive competition drives rapid innovation and continuously changing approaches in software development, there is little room for anyone to form a sustainable monopoly for significant periods of time. While it’s not unheard of, it’s rare. The most popular technologies that become ubiquitous at certain periods don’t remain that way for very long before someone comes up with the next big thing. No one can comfortably own space for long unless they understand that they need to stay on their toes in order to stay relevant.
I experienced this when I set out to learn React and React Native in the past year. In 2018 alone there were so many releases of these programs, with each one bringing in new features, fixing bugs and improving old functionalities. Everything just kept changing and improving!
As a result, while I can create some pretty complex React components, I have never really gotten to a point where I feel like I know the ins and outs of React. I was uncomfortable with that initially, but I’ve learned to be okay with it. Always knowing that there’s something I don’t know yet keeps me learning as I try to keep up with the pace of innovation.
How this influenced me as a software developer
- I have learned that no solution is ever really complete in software development — there is always something that can be improved.
- I have adopted the mindset that once we have met our target and shipped the product, it is time for us to relook at our solution and think about where we can innovate.
- I have realized that there is a continuous need to improve performance, increase efficiency, provide better user experience, etc. In development, as soon as something is complete, it is time to take it apart and rethink it.
- Knowing that the technology around me is always changing keeps me excited about software development every day.
Your thoughts?
I believe there is a lot that we can learn, not just from civil engineers who became software developers but from lawyers, doctors, taxi drivers and dozens of other professions. Have you come into software development from a completely different background? What have you learned? I’d love to hear from you.
Top comments (0)