One year down as a Software Developer after a boot camp! Everything I’ve learned so far.
There is so much to say about my first year. I’m having a hard time knowing where to start.
However, for an intro, I was a videographer/graphic designer that decided to switch careers into being a software developer. I had no idea what that would mean. I knew it would be hard, but I felt ready for that. I decided to switch my career because I was unhappy doing what I was doing and I was burnt out. I wanted a better work-life balance and I didn’t want something that could easily be replaced by a ‘know-nothing’, cheep intern. It was terrifying at first, but knowing that Software Development was a growing industry and that it required an expert that couldn’t be replaced by a local teenager, and that it paid well was enough to justify the gamble.
But enough of why. What did I discover? What happened?
After graduating from the in-person Flatiron School in Web Development out of the DC campus I had no idea what it would look like to work for a software company or what my actual day-to-day would be. However, about a month later (yes I said a month later — super duper fast) I got hired by a cybersecurity company out of Baltimore, MD. Here I learned so many things.
1. Sometimes they put you in testing
At the time I found it, it was a start-up (and still is technically speaking). I was someone that they hired to work on their end-to-end testing which was an area that was growing in their company. (Well, actually each and every team was growing at their company.) Since I was a recent boot camp graduate without any real-world experience, Testing is a common area for beginners since it’s a safer and less intimidating place to start and since it isn’t a skill that is taught anywhere really, people want to make sure that you learn good testing practices before you move on to working on real-world tasks. It helps you get your sea legs before sending you out to sea. And even though I said that each team was hiring — often the ‘new-to-coding’ or ‘fresh-out-of-college’ or ‘first-years’ (as we called them here) guy focuses on testing on whatever team it is. For me, my team was thee testing team for the entire app. But others were hired to focus on adding/fixing tests inside whatever team they were first sent to, which could be any team.
2. There are more jobs, teams, and areas of expertise out there than I thought.
I work at a cybersecurity company, so I can’t say that this applies to each company, but there are things, that I’m sure of, are fairly universal.
Outside of the teams that work on the app itself which (depending on how large) could either be full-stack or just front-end and back-end. We have all three here. Some teams are divided by each product that a company offers. But that was expected. Here is a list of other teams that I didn’t know were a thing.
- 🔬 R&D: Research and Development
- 🧪 SDET: Software Development Engineer in Testing (which is me)
- 🔐 Security (here, we all have to learn about security — most places will have a designated team that specializes in it)
- ☁️ Ops: Operations
- 🤖 IT: Internet Technology
- 📝 Docs: Documentation
- 👩🎨 UI/UX: User Interface and User Experience
- and lots of possible others
How many teams and what everyone specializes in varies greatly! But eventually, as a company grows, tasks get sectioned off so that people can focus on growing issues.
Which brings me to the next point…
2. It is amazing how many tools, apps, and general tech is out there for the regular average software developer just to do their job.
Just to name a few (and not necessarily ones we use here either) there are…
- Data visualization: Grafana, Sumologic, Tableau, D3, Leaflet, Vega
- Project planning: Kanban, Asana, Monday, JIRA, BaseCamp, Trello
- General Communication: Slack, Microsoft’s Outlook, Google Email and Hangouts, Confluence, HighFive, Zoom
- Coding Sharing and Management Tools: Bitbucket, Github, Gitlab, SourceTree
- Testing & QA: Selenium, all the Smart Bear applications, Jest, Cypress, Sitespeed, Mabl, SonarQube, Postman, Percy, Screenr
- IDE’s: Atom, Sublime, VSCode, Eclipse (for Java), IntelliJ (for Java), and all the rest of the JetBrains stuff
- Other Tools: VictorOps, PagerDuty, Docker, AWS, Kubernetes, Azure, Okta, SequelPro, Sumo Logic
- JUST FOR JAVA: Jenkins, Hibernate, Spring, Maven, Apache, Tomcat, and Gradle
The list goes on and on and on and on…
Also, there are new apps, and new tools designed around helping tech and tech workers work better every day. The sheer amount of technology out there is astounding.
One thing to note is that you don’t need to know all of them, but it is good to be familiar with as many as possible. As you go about your career and things fall into a rhythm, it is easy to get comfortable with what you know and have. However, if you stop paying attention to new tools that are out there, you might miss out on a tool that could make your daily life better. Not to mention your app work faster, safer, etc. You can’t possibly know it all, but fight the urge to nestle yourself into what you know. Don’t stop exploring the terrain.
Another thing that I’ve realized is that becoming an expert in a field can sometimes just mean that you know how to use one or more of these tools really well.
For instance, let's take AWS (or Amazon Web Services). AWS provides 165 services in a myriad of things. It can take so much time and effort to learn a handful of tools and to know it well enough for it to be meaningful to your work. It’s fairly typical for someone to become the designated AWS expert for a company or group or even have multiple tools experts.
3. If you need something, you have to write a ticket.
This was super weird for me at first. In the beginning, it came across as dismissive and kind of rude. I didn’t know what “tickets” were. It reminded me of when I first started my boot camp and the instructors warned us that often times their responses to most questions might end up being “Google it” and not to take that the wrong way. It’s just that sometimes they might not know and the best place to go would then be Google. I have since discovered that each task or to-do is called a ticket. It doesn’t matter how big or small the task might be, you have to write a ticket. Even if you are talking face-to-face with someone and the thing that you are asking them to do just requires to push a button for permissions — you have to write a ticket. This is not to make life harder, in fact, just the opposite. Companies try as much as they can (especially if teams are small) to know how much work each team/team member does, and unexpected work is one of them. They want to know how often developers get interrupted with work that is still ‘work’, but just not related to larger on-going projects. Being able to track this often gets used to justify where new hires need to go.
4. You should learn Java. ☕️
I’m not sure why but when I was at the boot camp, word on the street was that Java is a dying language. I don’t know where any of that comes from but at this point, I find that to be almost laughable. Java is everywhere and the biggest tech companies use it, like these here…
- Airbnb
- Uber
- Netflix
- Spotify
- Amazon
Java isn’t going anywhere. It is a super steady and mature language and it’s been around for years. It may have its downs, but it certainly has its ups. At Flatiron they teach Ruby for the back-end and Javascript for the front-end. I’m not sure why they teach those languages over others, but my guess is that it would be too much work to teach Java in a three month (15 weeks) program. However, that is just a guess.
Also to consider is that companies are not as flexible and inventive as people might think. When a company picks a language or a framework or what have you, they use that until they MUST leave it. It’s a lot of work for companies to update, change or rebuild that most of the time they don’t.
Also, for Java to go away you would need to stop each and every college around the world from teaching it. Did you know that in the USA alone 41,000 students graduated with CS degrees speaking Java last year? Java isn’t going away! 🤣 It’s just not happening.
5. You don’t need to know everything now.
After the boot camp, I was panicked about knowing everything as fast as possible. And not only that but I felt overwhelmed and upset for all the new things that I learned in coding after my time there, thinking to myself, “How did they not tell us about this!”, “This should have been covered in the curriculum!”. The number of new words and acronyms never seemed to end! IAST, RASP, OWASP, KPI, POC, SDET, R&D, ASG, ROI, XML, CI/CD, SAAS & SASS (I mean really?!?!?!🤯🤬), parser, builder, injectable, lazy loading, monkey patching, duck typing, transpile, websockets, daemons, stubbing, fixtures, hooks, proxies, orbs, containers & images, beans, type-casting, generics, race conditions, unit tests, integration tests, major, minor and patch. (Most of these have to do with security, testing, and learning Angular and Java.)
After working in a company for a year now, I have come to realize that you will never, ever know everything. If it isn’t a new tool or app to learn, there are new coding principles to learn all the time. If you speak one language, chances are, at some point, you need to learn another. Each language works differently because each language was written to solve specific problems. There are principles that are commonplace among many or most languages, but still, each language is different. Also, the languages are being updated all the time and tools around them are developing all the time. You will never know it all because all of it is changing so often. A boot camp can’t possibly teach all of it to you. The point is that they teach you enough to do some damage and to understand the most important principles that are mostly universal — in regards to Object-Oriented Programming — but that’s all that they can do. The rest you are learning on your own, or with a team, or with friends/like-minded individuals.
6. Read The Phoenix Project or The Unicorn Project
These are great books to read if you are entirely new to the industry like I was. These are NOVELS so they are fun and engaging stories about the industry inside imaginary companies. They are a great and fun read! What was great about these reads is that they help you know more about the actual day-to-day life inside of a software company. But what is great is they come from the perspective of how not to do things. In these books, you watch how these characters fix and then save the companies that they work for. You learn alongside them how a company should work and how software developers should develop. It helped give me perspective about how things started and why things are the way that they are and I could not help but compare my own company with it and appreciate the things it was or was not doing by reading these books. I also greatly appreciated what I needed to do as a Software Developer in Test because, especially The Unicorn Project, it has some great stuff about how that job, in particular, should be done to be the most effective and helpful in a company. I learned so much from these books and newbies should read them too! I’m being dead serious!
Closing Thoughts
For me, the new normal was so radically different from my old normal that it took me some months to settle into my new role. Not just getting onboarded into the code base but new work expectations too. I never worked at a place where you were allowed to have a life and time to research and learning a thing was worked into the schedule of a project. In my previous life, there was a pressure to lie about what you knew. You never admitted to not knowing something. You never said, “I don’t know. Let me go find out.” You just said, “Yeah I can do that” and then you spent the next how-many-hours-you-had-before-doing-the-thing researching, in secret, before show-time. It wasn’t ever said out loud, but it was heavily implied that you lied your way to the top. You never let anyone know what you didn’t know. You had to look like you knew the answer all the time. Because in the end, these companies didn’t hire you to learn the thing. They hired you to do the thing, which you should know before showing up. Learning, researching, experimenting — that’s done on your own time. They aren’t paying for that. Besides, most of the deadlines that you are working with don’t allow for enough time to experiment anyway, so what’s the point!
Now not all people working in the digital arts have the same experience as I do. Some people get hired by studios that negotiate deadlines, money, schedules, expectations, and rights. As for me, I worked mostly for small companies as an all-in-one shop and I worked doing their social media campaigns. Being so inexperienced, I didn’t know how to negotiate, do contracts, or set reasonable expectations. But the most frustrating thing about all of this is that people didn’t want to pay me for my work. Too many people saw my work as being easily replaced by their teenage kid, or (to my extreme annoyance) a company would hire an intern with no video or photographic experience and then ask them to learn on the fly because hiring a digital media student that knew how to do all of that already was too expensive. I too often found myself overqualified for the job that people didn’t want to pay me for. And the hustle to find new clientele was enough to be its own separate job that I didn’t have the energy for.
So from this life, I started a new life, with the most stable work/life balance that I ever had and got paid good money to do it too. I wasn’t replaceable anymore.
But with that said, I had PTSD from those days that I brought with me into this new life. I had days to work on something, which I was not used to. My first assignment was to research for as long as I needed a new tool that the company wanted to try out. I was so overwhelmed with all the new things in general that I felt like I didn’t do anything for the first month and I was constantly terrified that I was going to get fired. The second month wasn’t that much more productive either, but my manager kept assuring me that I was doing fine. “But that can’t be true”, I thought. I was too slow! I had a task that they needed me to do some research on and then fix. I did my research on it. I concluded that it wasn’t possible to fix going the route that we were going; a senior engineer looked at it and found a solution to it in minutes! A half-hour later I found myself crying in front of my boss. I felt like crap. Like a huge pile of crap. I thought for sure that I wouldn’t last long here. But I never was fired. I never got yelled at. They told me I was doing good work and that I was fine. Those first 6 months were the hardest for me and I still can’t say how grateful I am to have found a company that values the work I am doing even more than I am. With time I have come to understand a lot more about how everything works with each other. How smaller pieces fit in with the bigger pieces and how the company works itself. I’ve even learned, little by little, more of what the industry is like outside of the headlines, tv shows, or movies that I had been exposed to before.
The Real Conclusion
Software Development is all about research, experimenting, and learning. That will never go away and will never stop. It will become the defining part of your life. Even when I felt like the crappiest developer in the whole world, I still taught new things to senior developers without really meaning too. No one knows everything. No one. The most brilliant engineers here at my company who are doing things that no one else is doing in security, still get really shaken having to speak in front of others because they are nervous of looking stupid.
Don’t get frustrated! Don’t give up! Keep going and learn all that you can. You can do this.
