Eslam nasser
Posted on December 16, 2020
Post navigation
- Getting you up to speed
- Initial responsibilities
- Persuading the board
- Tech stack
- The first project
- The second project
- The impact I made
- What I have learned?
- Tl;dr (Summary)
Getting you up to speed
I live in a country where you have to do conscription right after college, the conscription is usually about 14 months.
In the army, there is no such thing as a "Programming soldier" or a tech soldier but one of the main officers had the vision to get someone with a programming background to build some solutions that can solve/automate major tasks, fortunately for both of us he stumbled on me with sheer chance and I told him that I'm a web developer with 5 years of experience, not just a fresh grad so he saw that I was a possible fit for his vision so he enlisted me in his institution.
After a rough two months of mandatory basic military training, I was ready to be assigned to my role.
Initial responsibilities
My first task was to improve an old system that was built years ago with Java-Oracle, the developer was a fresh SC graduate but unfortunately, he didn’t have a lot of practical experience so the overall product was not up to standards and didn’t solve any of the problems in hand.
The app had horrible UX and UI that made the usability another added issue to the pile of issues we need to solve, so when the main officer asked me to improve this app and make it usable, I spend a week learning the app and what it's trying to do, then I realized that I can't actively work on the app without taking months learning Java and Oracle, I couldn't spend this much time without any real progress that the officers can see so learning Java was off the table for me.
Building a new program is inevitable but I had to convince the board that we need to build a new program from scratch.
Persuading the board
I spent another two weeks doing some extensive analysis for the whole working process/cycle of our institution and learned why an app/program would be so important and found out a lot of processes could be automated and save tens of hours each week. After tons of brainstorming and wireframing, I finally had strong enough ideas to be presented to the board of officers.
My suggestion was to throw away the old program and to build a new and better one from the ground up with the promise that it will solve almost all of the problems (the ones that can be solved with tech) and even automate a lot of repetitive tasks that can save a lot of time.
After almost a 3 hours meeting that had A LOT of questions and concerns they finally took the leap of faith and gave me the green light, I had convinced a board of officers in a major military base to give me 6 months to build a new program that can solve a lot of the issues with very high efficiency and accuracy…
What could go wrong right? :’D
Tech stack
Luckily there were no guidelines on the tech I can or can’t use, I was free to choose anything I see fit and because I’m a Javascript developer the stack was like this:
Node/express: for maximum flexibility
MongoDB/Mongoose: some of the apps had relational data but I’m much better with MongoDB than MySQL/PostgreSQL so I had to choose MongoDB because I didn’t have the convenience to learn and work at the same time, but overall MongoDB/Mongoose got the job done pretty well.
Twig: templating engine for node
Vue: I used Vue as a general-purpose javascript library in a few pages that had reactive needs.
Electron: to convert the node app to a desktop app I had to wrap each app in an electron wrapper, this made the apps more stable and easy to install/uninstall just like any simple desktop app but has all the powerful nodejs features internally.
The first project
So far only one month passed, and I had tons of things to learn about the work mechanics of our institution, I spent another month working manually with my colleagues to truly understand the issues they face and what tasks can be automated.
Over the next 4 months, I worked 14+ hours daily for 20 days a month, I was a one-man team working on everything starting from database diagrams and UX/UI design to front-end and back-end all the way to testing and QA.
The board was following each step of the way and I insisted we do feedback cycles between me and the board to make sure our visions are always aligned and there is no wasted time on any deviations.
The fifth month was for testing and finding any kind of bugs, the testing actually went smoother than I thought and I got really good feedback from the employees that will be working with the app I made.
The second project
An opportunity opened for a second program we had to build asap, you can think of it as a large database of people each has his profile with all his info and service timeline, pretty straightforward.
The old “database” was simply a very large excel sheet and it was very unreliable, slow, and counterintuitively structured so when the board saw I was doing a good job so far with the first app they decided to switch attention to a more urgent problem and they permitted me to temporarily stop working on the first project till the second project is completed.
The database app was much simpler than the first app but few things were tricky such as:
I wrote a node script to convert the excel sheet to CSV then to JSON then imported to the database directly, the script worked well but the problem was the majority of the excel rows didn’t have the same structure so we had to manually organize tens of thousands of rows, that took few days working straight all day and night.
One of the app’s main goals was to easily handle actions on a large set of records, so for example, if want to apply some action on a 1000 record I don’t want to manually do it on each record individually so I had to create a “mass-actions” feature, I enjoyed this part of the app a lot :D
Some of the records were pretty old and some were missing a few critical info so I had to build a few scripts that search and patch these cases if it’s possible to guess the missing info and in other cases, it was impossible to guess so we had to manually collect and patch these records.
I was a bit naive when I estimated the effort needed to build this app, it took about 7 weeks to build a stable enough version to be used in production, my first estimations was 4-5 weeks.
The impact I made
Obviously, I can’t share any detailed description or even screenshots of the apps but what I can share is the impact these apps made on the institution.
The main goals of any of the apps are :
Reliability, by building apps that are strict with their data flow and the process and somewhat excessive data validations, you can trust that info/stats/reports you get from the app are very reliable, this is extremely important for decision-makers to help them make the right decisions depending on very detailed and highly accurate reports.
Learning curve, each employee/soldier only serves for 1 year, so when a new employee comes someone needed to teach him all the workflow and how things works, that took weeks in best cases, now the handover can take only a few hours (a couple of days in worst cases) and anything that not clear you can found in the user manual and FAQ.
-
Saving time by automating as many tasks as possible :
- 5+ hours in daily tasks
- 20+ hours in weekly tasks
- 100+ hours in quarterly tasks
- Some tasks took 3-4 weeks to be done now it’s done instantly by one single click
- Mass-actions is a concept where you can select a subset of records and apply a set of actions to all of them at once, which reduces some tasks' duration to a fraction of time previously needed.
What I have learned?
Trusting myself: No matter how scary the situation looks, I have to trust myself and my abilities to get the job done, I was very intimidated at first by everything, I was waaaaay out of my comfort zone and the usual clients I deal with.
Do my homework: Doing tons of research and planning can help a lot in project briefs/presentations and building self-confidence (If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax, Abraham Lincoln).
I’m not always right: The end-user is the one who can truly say if the app is helpful and achieved its goals, not the manager, not the board, not the developer, only the end-user.
It is not just coding: Balancing between the board’s goals and end-user needs and meeting each deadline was extremely hard for me and I guess I did a good job at it by listening to all sides and evaluating what’s best for the project, then building a case for my decision to present it when needed.
Discipline: to meet the deadlines I had to make a very strict schedule with 12+ hours of work each day, I was a soldier in a military base with literally nothing to do but work so luckily sticking to my schedule was not that hard.
Empathy: the two main apps I made was going to drastically change the workflow of several employees, some of them was working the old ways for years now so the idea of changing their workflow was very upsetting for them as it may introduce new responsibilities/accountability to them, of course, I understood their concerns and had to absorb them and ease their fears into the new workflow, showing empathy to them greatly helped the transitioning process.
-
Perfection is the enemy of progress: I will never be a perfect programmer nor my apps will every be and that’s okay, near the end of my service I had a lot of doubts about my work quality and if I could do better, these apps should run for years and years to come and there are no other developers in this institution and probably will never be, what if there is a critical bug surfaced in the future? What if for some reason one of the apps didn’t want to start? What if a major data loss occurred?
All these questions kept me awake in my last nights in service, I doubled checked everything and then checked again and again, I wrote FAQ for all the possible questions and scenarios I could think of, I recorded videos that shows how to setup/relocate/delete each of the apps and more topics like automated backups and maintained the internal network in the department, I wrote technical docs for any developer that can come in the future.
-
I have grown: it was a very different experience than any company/freelance job I had, it taught me a lot of skills that I hope I can carry within future challenges, skills like:
- Working on long-term projects and learning how to build apps that should survive years to come.
- Working in a totally offline environment, yeah … I didn’t have internet access while I was developing.
- Putting planes for months forward and making sure I stick to them.
- I have a much better understanding of how much effort it really takes to build apps that fully satisfy the business needs.
- I expanded my technical knowledge to cover some aspects of networking, UX, projects management, negotiation, and further improving my existing technical skills.
I know most of these points can look obvious to most people, but knowing something and seeing how it works in real-life situations are two different things, for example, everyone knows how discipline helps you achieve your goals but actually planning and strictly sticking to it (using the military lifestyle) helped me achieve goals I didn’t know I can achieve!
Tl;dr (Summary)
I worked as a programmer while I’m doing my obligatory military service. I learned how the institution works and built a few apps to solve some major issues they face in their institution.
The impact I made can be summarized in :
Building highly reliable apps help high-level decision-makers by providing very detailed and highly accurate info/stats/reports
I decreased the learning curve needed for new employees from a few weeks to only a couple of days.
Saving hundreds of working ours by automating tasks and building custom bulk-actions solutions to handle large amounts of data.
What I have learned can be summarized in :
Trusting myself and my skills to handle any situation and not be intimidated.
Doing a lot of research is extremely helpful to have the self-confidence to give powerful presentations and push your ideas.
The end-user is always right because at the end of the day they are the ones using the apps and the ones who can truly say how these apps were impactful.
It is not just coding: Balancing between the board’s goals and end-user needs and meeting each deadline was extremely hard, I did it by listening to all sides and evaluating what’s best for the project, then building a case for my decision to present it when needed.
Discipline: to meet the deadlines I had to make a very strict schedule with 12+ hours of work each day, I was a soldier in a military base with literally nothing to do but work so luckily sticking to my schedule was not that hard.
Empathy: I understood the employees’ concerns about the new apps and had to absorb them and ease their fears into the new workflow, showing empathy to them greatly helped the transitioning process.
Perfection is the enemy of progress: doubts about your work can be useful to push you to a more quality project, but too many doubts can have the reverse effects and blind you from how far you came.
I have grown as a developer and as a person by expanding my technical knowledge to achieve these goals and expanding my communication skills to collect all the requirements I need and negotiate deadlines.
Sorry it was a long one, but it was a long journey.
Thank you so much for reading.
Posted on December 16, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.