The offer I had last accepted was for a company called MRG Solutions. It was a company which does engineering consulting, mainly inside the oil and gas industry. Knowing how dependant the world is on oil left me with the warm and fuzzy feeling of job security. Though this was short lived after I realized how dependant our company was on the price of the oil. The job was a junior developer position working directly under the relatively quiet, light hearted development manager. I remember in the interview, he was more excited to have me join the team than I was! After accepting the offer, I was then informed that the company was being acquired by Emerson within the next year, which I was indifferent to at my junior level.
The company was located in Sandy Hook, CT, right inside an old mill factory. The interior of the building had beautiful natural exposed wood architecture which gave you the feeling of inside a historical artifact. There was a peaceful stream rolling behind the building which was a pleasant sight to see every day while walking in to and out of the office.
The main body of work I was hired for was to support an application used by the engineers in the field, called Catapult. There were asset management aspects to the application, building bill of materials, reporting, etc. It was a behemoth of a code base.
Being overtaken by this massive codebase, I chose to reorganize the libraries a bit and refactor the code so it was easier to navigate and less grandiose. That was my first mistake working there. My manager calls me into his office and proceeds to berate me for messing up the stable code base. In hindsight, I can understand his frustration. Some new guy coming in, judging and ripping apart the work he had spent the last 10-15 years writing. It definitely was a kick to his ego.
A few months go by and I keep busy by chiseling away at the backlog for Catapult. Eventually, the COO of the company recruits me to build a new performance management system. The way the were tracking their practitioners key performance indicators was through a complicated process of extracting from the HR system, loading into a database, calling that database a “data cube”, and loading a bunch of excel reports from that “data cube”. It was a mess. From the extensive lessons learned from my former co-worker and data enthusiast Keith, I was appalled at the bastardization and improper use of our sacred passions!! But I digress.
My instructions were to take the spreadsheet and make a reporting application and dashboard using the same source data as in the spreadsheets. I ran with it (even though the “data cube” was a OLTP database). I produced a pretty functional application that looked nice within a month. I designed the architecture, chose which technologies, implemented IoC containers, and coded every line. This application was my magnum opus for this company. Catapult will live on whether I stay here or not, but my app is how I would be remembered. If it screws up when I’m gone, it’ll be “God damn Steve wrote this crappy application”, or if it is a success, it’ll be “We are so grateful for this wonderful application”. I felt immense accountability for the success of the application, which we then coined, OPIS Operational Performance and Information System.
Around this time the company started becoming Emerson-ized. We started getting added to their network, getting new email addresses, and told that we were going to be moving to Watertown. The timing was great because I was looking to move in the same time period.
We moved to this flat, ugly, bland looking building, both inside and out. The interior had white painted bricks for every wall and the distant clanging of workers in the factory. I was worried that my cubicle wouldn’t have a window so I had said jokingly to my manager, “You guys better give me a window!” To my disbelief, it worked, I got a window seat, but it was right next to the entrance. So, I was privileged to feel the cool breeze of every employee walking through the door. All in all, pretty smooth transition.
Things here started becoming pretty routine. We would go on a walk through the suburbs during lunch almost daily. I would be the primary Web developer for our section of the company and my manager would be the win forms developer. I was eventually promoted to mid level developer. In all honesty, I didn’t deserve to be promoted at the time but was in fact an HR technicality because of salary grades. That’s how many people get through the ranks of being a senior developer. Time. That is of course applicable to the “classic corporate” model of growth where you have dev 1, dev 2, dev 3 style titles.
I can say with confidence that at that moment I was experience symptoms of impostor syndrome. For those who are newer in this field or are unaware of this condition, here is the wikipedia definition.
Impostor syndrome (also known as impostor phenomenon, impostorism, fraud syndrome or the impostor experience) is a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a “fraud”.
Wikipedia contributors. (2019, March 19). Impostor syndrome. In Wikipedia, The Free Encyclopedia. Retrieved 14:09, March 19, 2019, from https://en.wikipedia.org/w/index.php?title=Impostor_syndrome&oldid=888434541
Most developers experience this at some point in their career. Either they get a project that they don’t understand, get responsibilities they believe they aren’t ready for, are in charge of people and feel unqualified, etc. Utilize this feeling for self improvement. Confront your fears square on. If you feel you are lacking technically, then get off the video games and start taking courses on your weaknesses. If you feel like you have too many responsibilities, automate them wherever possible. Imposter syndrome is a temporary state of mind and all states of mind can be controlled yourself.
Though I believe in the frequency of imposter syndrome, I think the opposite syndrome needs to be brought to the awareness of people in this field.; the Dunning-Kruger effect. This is where a person has such a delusional superiority, usually to their coding abilities, which usually will get interpreted as arrogance.
Wikipedia contributors. (2019, March 14). Dunning–Kruger effect. In Wikipedia, The Free Encyclopedia. Retrieved 14:19, March 19, 2019, from https://en.wikipedia.org/w/index.php?title=Dunning%E2%80%93Kruger_effect&oldid=887735939
In my opinion. a way to combat this is by maintaining a learners mindset. Understand, that it is physically and metaphysically impossible for know person to know everything and chances are, you’re wrong anyways. Refocus into team orientation rather than the individual orientation that is the root cause of this effect. You believe your contributions are of more value than everyone else.
“The only true wisdom is in knowing you know nothing.” ― Socrates
- Just because you are technical, doesn’t mean you should focus only on programming. The industry you’re in is just as, if not more important than your technical work.
- Communicating an idea effectively is more important than fast execution of that idea.
- All promotions are deserved, even if you didn’t feel like you deserved it.
- Being aware of imposter syndrome and the Dunning-Kruger effect reduces its’ occurrences.