Learnings & reflections. Updated weekly.
- Apprenticeship weeks 20 & 21 focus: automated testing (end-to-end or e2e, feature, integration, unit), the testing pyramid (UI, service, unit), test-driven development (TDD) - "red, green, refactor", Arange-Act-Assert, Four Phase Testing (setup, exercise, verify, teardown), fixtures (fixed data needed to set the stage for a test) vs. factories (helpers that generate data on-demand), fakes, stubs, spys, mocks, test semlls
- Friday huddle on surviving volatility in the job market
- Regex - url links
- constants.ts
- financial planning basics
- Apprenticeship week 19 focus: things to focus on when solving algorithms especially during interviews, case sensitive or not, considering all edge cases, writing out pseudocode steps, asking clarifying questions, considering factors such as performance and efficiency, asking AI to tell you potential issues with your solution, etc.
- Equity in Action panel discussion on Friday: "green flags" of equitable organizations, diversity in tech, say/do ratio, being a mentor, advocate or a sponsor for someone else
- Design patterns and code smells: Gang of Four design patterns, Digital Ocean tutorial Gang of Four design patterns, Refactoring Guru design patterns
- https://sourcemaking.com/design_patterns
- https://roadmap.sh/software-design-architecture
- Head First Design Pattnerns
- Unit testing: write in small chunks and test coverage as you go vs. writing a full test file, observe the change in code coverage
- Decomposing and really "groking" problems.
- Feeling impatient or a sense of urgeny, and how that can prevent you from grokking - "Urgency is a myth"
- Getting better with front-end UI work and design after pair programming with my senior dev
Fun fact I learned this week: "Grok" is a term commonly used in the tech world that was first introduced in Robert A. Heinlein's 1961 science fiction novel Stranger in a Strange Land. In the book, to grok is to empathize so deeply with others that you merge or blend with them. The simplest way to think of grok is as truly, deeply understanding someone or something in an immersive and experiential way. In the tech community, it is used frequently to represent deep understanding of a topic (thinking semantics vs. syntax again here). Even though I had heard the word "grok" before, it wasn't until this past week that I really grokked the word "grok".... (see what I did there?)
The past two weeks have illustrated a couple of additional areas I really want to grow, improve, and GROK. As I have previously written about, sometimes I am jealous that I don't have a 4-year computer science degree because even though the general consensus in this field is that you don't need a 4-year CS degree, I still feel there is a ton of "big picture" knowledge that one would gain in a 4-year degree program like that. I am hungry to expand my knowledge and grok computer science concepts, and this past week my senior dev suggested I dive into design patterns (which also commonly go along with code smells, which we have been discussing a lot in Dev Carolina workshops). I was able to order a couple of used books about design patterns on Amazon this week (Gang of Four and Head First Design Patterns) and I am excited to start digging in.
I was also able to see grokking in action this week when I teamed up with my senior dev on some frontend UI work, as well as with both my senior dev and my mentor on unit testing. As I have also written about previously, one thing that I have really had to work on is slowing down and not getting too impatient/eager to submit a PR, and that ties into this concept of grokking. When you slow down, you are allowing yourself to be fully immersed in a problem or concept, and that is when deep learning and understanding can happen. This has of course been challenging on-the-job when I feel that I need to perform as quickly as possible, but as one of my fellow apprentices said this morning, "urgency is a myth," and an engineer that really groks something provides more business value than one that is just putting out quick output in the short term. I want to be the first kind of engineer!
When I observed how both my mentor and senior dev set up unit tests, they were both very methodical in their process. They wrote out psuedocode first in comments of what needed to be tested. This involved truly grokking the feature or file you are writing a test for. When an error or unexpected behavior happened, both of them really dug into it to understand it and the behavior that is happening and explained their thought process to me. I also had the opportunity to work with my senior dev on creating a UI for a chatbot. While CSS and frontend work often makes me impatient, and I start just changing things willy nilly, my senior dev was really great about slowing down even when it comes to UI and design and trying to think through things logically. While I am not really giving myself enough credit for the ways I do grok things well as an engineer, I am seeing all of the room I have to grow and feel lucky that I get to work with some really badass and intelligent engineers.
Along those lines....I am starting to experience some feelings of sadness that my current routine and workflow will soon be coming to an end and/or changing. :( Even if I am hired on full-time, I may not be working with the same team, or even in the same department. Just this past sprint, the junior dev on my team Robyn was very suddenly moved to a client project, which we were all really sad about even though it is a great opportunity for her. This apprenticeship has been a really positive experience for me and I really admire and look up to the amazing engineers I get to work with at Booz Allen and learn from, both those that are at the same level as me and senior to me. I have also thoroughly enjoyed the Develop Carolina portion of the program, even though I know it will also be helpful to have less context switching during my weeks, etc.
As the end of the apprenticeship draws closer, I am starting to mentally and emotionally prepare for change ahead, and just noticing and working through these bittersweet feelings. In addition to continuing to learn as much as I can in this program and enjoy every second of it, I have made it a goal of mine to truly embrace this grokking mindset in everything that I do, both for work and the fullstack project Kyle and I are wrapping up. While this is not truly a measurable goal in some ways, I am hoping to be able to reflect on my progress a month from now to see how I have improved as I graduate and (hopefully) level up as a full-time junior engineer. <3
- Apprenticeship week 18 focus: clean code, code quality (volume, complexity, business), complexity (cyclomatic, cognitive), code smells, tech debt, refactoring strategies, capital "C" Clever, green flags of team dynamics, "make managers and team look good," grokability, signal vs. noise as it applies to clean code as well, bitRot, code quality automation (linters, CI integrations, third-party services), Chesterson's fence, salary negotiations and knowing your worth, job titles and paths
- Automating of code (AI tools) over time takes out innovation, only training on old materials, etc. (BitRot)
- The Campsite Rule applies to cleaning code "leave it better than you found it"
- Instead of asking, "is our codebase clean?" ask questions such as "is our system well-tested?", "how quickly can we onboard new engineers?", "are new features having the expected outcome?"
- "Praise publicly, criticize in private"
- Refactoring code smells: https://refactoring.guru/refactoring/smells
- Apprenticeship week 17 focus: clean code (comments, naming, formatting, error handling, functions, objects & data structures), DRY, Law of Demeter, everything has ONE functions/purpose/effect (Single Responsibility Principle), measures of code quality (volume, complexity, business), "garbage collection," Hungarian Notation, "Bike-Shedding" (focusing on inconsequentail details that don't matter to what you are doing), "swallowing errors"
- self-documenting code vs. adding comments for everything - hard to find balance, but comments can affect performance sometimes!
- Better understanding of JS error handling: https://www.w3schools.com/js/js_errors.asp
- Create & share images of code: https://carbon.now.sh
- Full-stack project feature #2 demos!
This week was a humbling reminder of just how far I have to go in this career journey and the difference between a junior and a senior developer. This past sprint, I have been struggling through a feature that involved authentication, creating a service and rendering it in a frontend component. There were a few unknowns and I was a bit stuck. When my senior dev sat down with it, he solved it in 2 hours (LOL!). As one of my mentors said: "at least he didn't solve it in 2 minutes." I immediately felt insecure about not being able to figure out this ticket on my own. But then I remembered that I have only been learning software development for a little over a year, compared to my senior dev who has been working in this field for 12 years now(!!!!).
There is a sort of cushion of security/safety in being a junior dev, and particularly as an apprentice right now, that it is okay to make mistakes and fail, and no one is expecting us to carry the team or anything with completing tickets. However even knowing this, I still am very eager to do well and perform, and I often have to sit in the vulnerability of my experience level. There is a dynamic I have felt throughout this apprenticeship of "I know what I am doing/I have no idea what I am doing," and from what I have heard -- to a certain extent -- this feeling will continue throughout your career. Knowing this, it is important to have the humility and self-confidence to be vulnerable with where I am at in my learning journey, and to see these struggles/challenges as markers for growth areas. This concept takes me back to earlier in the apprenticeship when we discussed the power of the word "yet." Everything is so new to me right now, but my knowledge and skill level is a temporary state that will continue to trend upwards as I learn and grow. After my feelings of insecurity this week, I am re-committing to myself that I will stay confident in myself in what I do know, while handling experiences like this (not knowing all the answers, needing help on tickets, etc) gracefully and with humility and patience. <3
At the end of this week, we had our second feature project demos, and Kyle and I reflected on just how much we have learned and improved over the course of this apprenticeship. I am so proud of both of us and am grateful to have developed an amazing friendship through working together on this project. Despite the vulnerability I experienced this week as a junior dev, I truly have improved my knowledge and skill dramatically over the past 6 months, and when I reflect on that, I am filled with so much gratitude and pride. I have a long way to go to get to a senior dev level who has 12 years of experience, but I know if I stick with it and keep a positive attitude and work hard, I wiill get there someday. For now, I am going to continue enjoying the journey, and practice being kind to myself throughout the insecurity of being a junior dev. :)
- Apprenticeship week 16 focus: programming languages, matching a language to a particular need, language learning strategies, syntax vs. semantics (syntax is the words, semantics is the logic we represent with syntax), common language considerations (community (Python, Javascript), concurrency - scalability and throughput (Go, Elixer, Rust), convenience (Ruby, Javascript, Java), conventionality (Java, C#)), importance of keeping up with learning throughout your career: Growth time/10% time, learning groups, internal project graveyard at work, mentorship, timeboxing, kata & koans, personal projects, open source
- Journey through language levels, from machine & binary to assembly level (Rollercoaster Tycoon was built on assembly!)
- OOP vs. functional programming: https://medium.com/arctouch/thinking-functional-now-with-example-and-cats-8b9c2478b9af
- Learn X in Y minutes: https://learnxinyminutes.com
- Rust & recent Whitehouse statement: https://stackoverflow.blog/2024/03/04/in-rust-we-trust-white-house-office-urges-memory-safety/
- Sessions are OBJECTS!
- Tyepscript, Next.js and Mantine UI as I work hard on the fullstack project frontend!
- Tyepscript interfaces & type definitions
- Nested serializers in Django Rest Framework
- Oauth flow, authenticating to GitHub Rest API
- Getting better at soliving algorithms in Javascript
- Don't be afraid to ask for help and pair program, etc. <3
- Work flow additions: Microsoft One Note and https://excalidraw.com for documenting ticket work and thought process, etc.
The past couple of weeks have been stretching my technical skill set, and I have really been trying to embrace this mindset of "it's okay to be stuck." I am also very grateful that this is the message being iterated to me from my senior dev and the rest of my team. In previous jobs (and I think just in US society in general), there has been such a heavy emphasis on your value and self-worth being tied to your work output and productivity. While I know logically that this is true, I am still working through finding that balance, and being comfortable with the discomfort of not moving as fast as I think I should be, etc. I am realizing that a lot of the pressure to work faster is coming from me, and not anyone on my team. Software development is a skill like any other, and junior devs, of course, are not able to produce as much and as quickly as senior developers. I am comforted by the fact that my team and everyone I am talking to in the industry knows this, and that there is safety in that.
While I of course have experienced the process of being stuck on coding challenges in my personal/academic learning journey, it has been a shift in my mindset to be okay with the process of being stuck on something while at work. My instinct at work has been to try and complete as many tickets as I possibly can within a sprint, and work as quickly as possible, thinking that this is how I demonstrate competency and provide value. But one of my mentors this week was talking to me this week about how junior devs often have a misconception about this, and that the nature of the work is that often, tasks DO take more time, and that doesn't mean you are not driving value. My tech lead also has iterated that it is better to slow down and really dig into a problem to better understand it, not just for your own growth, but for the benefit of the whole team, because you can then communciate that knowledge back to the team. Slowing down on problems also helps eliminate mistakes, so there is less back-and-forth with code correction when it comes time to submit a PR.
One of my mentors gave a great example of someone she worked with who really embraced this mindset of slowing down and as a result is a really strong engineer that she admires and aspires to be like. She told me how nothing got past this developer, his attention to detail was so strong. And even though he wasn't producing the fastest each sprint, she never experienced a time when his code broke in production. As a mentor, he would challenge her and ask her to explain her code, helping her to grow and truly understand the problem/concept and not just trying to solve it without truly understanding it. After hearing this story, it has made me feel that 100% I would rather be this kind of developer, than a developer who works super fast but often has errors or doesn't solve things in ways that will scale, etc. Her story of this developer reminded me very much of the "Be like Bob" meme, and it has made me want to generate a meme for software engineers that is called "Be like Chad." :D
A few tangible strategies that have really been helpful for me in embracing this mindset. Number 1, of course, is getting comfortable with the uncomfortable, and consciously trying to dig in and understand the problem, researching things I don't know, reading docs, asking CoPilot to explain a section of code so I can better understand what it's doing, and not being afraid to approach a problem from a different angle or try something without needing assurance or to check in with my senior dev. In short, just trying to "Be Like Chad" as a developer! Number two - trying to get more specific during my DSU meetings on what exactly I am stuck on (meaning, what specific part of the problem I am stuck on, and how I am thinking through it), and by doing this I am able to get great feedback and guidance during DSU, while also communicating potential issues to my team early as they arise. This past sprint, I was able to alert my team that an auth configuration had a much larger complexity than originally expected, and this communication helped us pivot in a different direction. Even though I didn't get to complete this ticket so to speak, I felt good knowing that I was contributing to our team goals by communicating the issues I was seeing. Number three, embracing one of my mentor's work flow additions of using Microsoft OneNote and Exalidraw for each ticket I work on. While I haven't used Exalidraw very much yet, I immediately was able to implement Microsoft OneNote to help with taking notes on tickets, brainstorming, keeping track of iterations, etc.
Lastly, not being afraid to ask to pair program something, or simply talk through a problem with a peer. This past week, I was able to make great progress on a ticket by consulting with the other junior developer on my team, who first helped me think of a different troubleshooting approach. We later were able to pair program together, and I was reminded of how powerful it can be when it is two people vs. one coding problem/challenge. This experience also was really great in helping us build trust and strengthen our work bond.
In conclusion, I am grateful for all of these awesome lessons learned, for the amazing mentors and developers I have around me to learn from and with, as well as the pscyhological safety on my team to be vulnerable and communicate where I am at on ticket challenges and progress. I am also excited to see how I have improved my knowledge of Typescript and Next.js in the past week just by digging in and spending more time with the language and framework. I love being in a career path that is constantly challenging me and where there is infinite opportunity to learn and grow. :)
- Apprenticeship week 15 focus: Open source software continued, programming languages vs. computer languages, markup languages, query languages, data exchange languages, algorithms, Alan Turing, the Turning Machine & "Turing Complete"
- Hoping to contribute to something here! https://github.com/rubyforgood or looking at language/framework source code
- Started learning the basics of Langchain! So cool: https://www.youtube.com/watch?v=bH722QgRlhQ
- Typescript course & cert: https://www.w3schools.com/typescript/
- Panel discussion with 4 software engineers in different phases of their careers and different focuses
- 2 1/2 years usual time in a role in tech
- Staying confident even when taking on more challenging problems & venturing into the unknown!
- Python cert: https://www.credly.com/org/python-institute/badge/pcep-30-01-pcep-certified-entry-level-python-programmer
This was a busy and challenging week for me, and I felt a little more stress than usual. I think there were a few contributing factors, aside from some things going on in my personal life. Last week at the start of our sprint, I bravely picked up a 13 point ticket with multiple subtasks that ended up having several unknowns, requiring us to pivot. One of my tasks involved configuring authentication, which can be challenging in a personal project alone, let alone on a project with a company firewall. But I am happy to say I figured out this subtask and was able to move forward. On a separate ticket this sprint, I was also able to start learning the basics of Langchain, which I am really excited to keep digging into.
At the end of my week, I started working on another challenging ticket that involved setting up a new project feature using Typescript. There was not very much documentation readily available to help me with implementing this functionality, and I was also experiencing my first round of Typescript errors, as I have never built in Typescript before. I also had time working against me, since it was late in my 3-day work week, and at the end of the sprint. On Friday AM, I was able to show a rough draft of my code, but I felt self conscious because it was still broken, and I was also still figuring out what needed to be done and troubleshooting. It is definitely challenging for me to be vulnerable with showing a project that is not up to my standards or completed, but I was happy to at least show some working progress to my team and communicate where I was at with it. I think one of the challenges I have been experiencing is feeling like I wish I had more days in the sprint so that I could get more done (since I am only there 3 days/week, the 2-week sprints go by very quickly) but after talking with my mentor, he assured me that my velocity is still great and to have patience and grace with myself on this.
Between this ticket and then also needing to complete the cart and order functionality in our Fullstack project, it has made me realize I need to take a quick step back and better understand Typescript. I will be working through a tutorial this weekend that I believe will help me with both work and the project. While I definitely enjoy just getting into the weeds and scrapping around and troubleshooting problems, there is still something to be said for pausing and going back to the basics, going back to a tutorial or documentation to better understand and improve your knowledge.
Aside from these challenges and some personal stresses going on, I really loved our Friday panel discussion with 4 working software engineers. They each had very different backgrounds and experiences and were in different stages of their careers, and it was a very insipring conversation! Here were some of my takeaways:
- Be vocal about what you want, about your interets and the projects that you want to work on
- Ask questions but be sure to ask informed questions
- 30:60 rule for working through a problem - 30 minutes working through it in code, 60 minutes researching, then ask a question if needed
- Be proactive about taking on more or things you want to do
- When thinking about velocity and priorities, be sure to communicate what needs to be done still even if you need to switch gears and move on to something else. Sometimes it is time to move on from a task even though it isn't perfect <3
- A masters degree in Computer Science will not bring about a financial return or help you get ahead per say, but still worth doing if interested and seeking additional education
- AI will continue to change the tech industry, but it is important to continue to master the fundamentals and focus on researching problems, especially early on in your career
- You should try & have a personal project going at any given time to continue expanding your skills and learning and growing
- Continue to push yourself out of your comfort zone, take on projects and technologies and tickets that challenge you.
Reflecting on this last takeaway, I feel grateful that this week stretched my technical skill set. Rather than focusing on the vulnerability of that, I am going to embrace the challenge and embrace being a bit uncomfortable. I look forward to reflecting back on this day when I am way more experienced, and I will be able to see tangibly how much I have learned and grown. Even now, it still surprises me where I was a year ago, and how far I have come. My journey in software development started in January of 2023, and when I remind myself of that, I feel so incredibly proud of my myself, my work, my growth and progress, my patience and grit. <3
- Apprenticeship week 14 focus: Open source software, ethics in open source, software licensing (use, modification, distribution), different software licenses (MIT, GNU GPL, Hippocratic License), contribution ediquette, Friday Huddle on performance evaluation in tech
- https://choosealicense.com
- https://creativecommons.org/share-your-work/cclicenses/
- Observations of how senior engineers solve problems (isolating, simplifying, etc.)
- Importance of tying your work to the goals that matter at your company. Be aware of how your work is creating value. "I did this, and now... so that... as a result...etc."
- Finished order and carting processes in Food Connect API! Moving on to Next.js and Mantine componenets in the frontend of our project :)
- Apprenticeship week 13 focus: Reflection/recap of apprenticeship progress so far, fullstack learnings, the Pressure Performance curve: owning your career journey, work-life balance vs. work-life harmony, Friday huddle focusing on self-care and boundaries
- Your Portfolio is a representative of your learning journey - it tells the story of your learning progress and is a conversation piece. It is always a worthwhile practice to revist portfolio to rework old projects.
- Jobs as software engineers "How can we make our client look good?"
- Nonviolent communication: "it's not you vs. me, it's us vs. a problem"
- "Clear is kind" - the gift of clear feedback. Clear feedback is giving someone a perception they aren't seeing. It is taking the sticky note off of their back.
- "The only people who get upset when you set boundaries are the ones who benefitted from you not setting them"
- Yogi principle of finding the balance between "sthira and sukha" (effort & ease): https://www.ekhartyoga.com/articles/practice/sthira-and-sukha-finding-balance-on-and-off-the-mat
- Additional experience with being stuck on a problem for a long period of time
There have been times within this apprenticeship when I really feel like my learning comes full circle within the week in all areas of my life: in our Dev Carolina workshop and huddle, in my Booz Allen work, fullstack project work, and in my life outside of these three things. This was one of those weeks, and the underlying concept I've been reflecting on came from my yoga class on Monday night where the teacher talked about "sthira and sukha" - finding the balance between "effort and ease."
- Sthira refers to stability, intent, effort and strength. Etymologically it arises from the root stha, which means “to stand, to be firm”.
- Sukha refers to comfort, ease, and openness, and the literal meaning is “good space,” from the root words su (good) and kha (space).
When I first started practicing yoga, I was very much focused on the physical aspect. An athlete all my life, I knew that increased flexibility and mobility would help me improve in my sport and perform at my very best. The "sthira" was what I was good at, what came naturally to me: always going, going going... working hard, trying to be perfect, staying busy and stressed, and ultimately, getting burnt out. What I needed to learn was the "sukha" part: finding grounding and relaxation, and learning how to be still.
As with many things in life, my understanding and learning journey with yoga evolved over time, layer by layer. While I was introduced to yoga in my teen years, I would say I didn't begin practicing it more seriously and more frequently until about 2017. The more I practiced, the more I realized how yoga is truly guided by the breath -- moving in sync with the breath. I was also introduced to the challenge (and frustration) of meditation: trying to keep the mind still and present, even while thoughts are rushing past. In January 2020, I attended a yoga retreat with Jonny Kest and something he said then has stuck with me: "The moment you want to get out of a pose is the moment when true yoga begins."
While I didn't quite grasp this concept at the time or see how it was applicable to my life off of the mat, over the past 4 years, my understanding has evolved. Both sthira and sukha are essential in yoga. The sthira is the "fire" of the pose, the part that requires you to bring strength and intention and be fully present, even during discomfort. And then once you are there, the "sukha" is finding comfort and ease in the moment. Similarly, when it comes to life off of the mat, it is so important to balance work with play, effort with ease, strength with gentleness.
I hadn't seen the Pressure Performance curve before, but it is a guiding tool our Develop Carolina mentors use to try and gauge how we are doing throughout the apprenticeship. The goal is to be in the "sweet spot" of effort and ease: where we are being challenged and stretched, but not straining, and striving for the balance between "boreout" and "burnout." Understanding that this as a guiding concept our Develop Carolina leaders are focusing on for us apprentices makes me so grateful to be a part of this program, which is truly about taking a holistic approach to helping us become full-time software engineers.
Similarly to yoga, sthira and sukha are essential in software development. As a junior dev, it is important for me to bring intention, effort, and strength to working through challenging problems, even during feelings of discomfort or frustration. At the same time, it is just as important for me to find comfort amidst the discomfort, to let go of ego and remain open to receiving feedback, to ask for help when I need it, and to give myself grace and compassion in my learning journey.
- Apprenticeship week 12 focus: Human-centered design, User Interface (UI) vs. User Experience (UX), wireframes & mockups, observing a system affects the outcome of the system, Schrödinger's cat, user personas, design thinking, how to support UI/UX designers on your team
- Design terminology course: https://app.uxcel.com/courses/design-lingo
- Single tasking vs. multi-tasking
- SSL/TLS certificate validation, CA's, proxy
- Django user authentication & authorization with a custom user model
- Docker (when in doubt, 'docker system prune')
- Environment variables
- yaml files (ugh!)
Reflections - "It's okay to be stuck sometimes" - "Am I still being productive when I am stuck on a problem?"
We are officially half way through the Develop Carolina experience! On the one hand, the first half flew by and I can't believe we are already at the halfway mark. On the other hand, I can very tangibly see how much I have learned so far in the past 3 months, and I recognize how this experience has really helped me improve my skills and grow as a person and professional in a number of different ways. For example, I now have the confidence to approach any unknown problem/language/framework, since that is what I do every day at work with different tickets. I am recognizing that the real skill of software engineering is problem analysis and troubleshooting, and I have worked this muscle so much in the past 3 months that I can really see an improvement in my approach to problems and my overall workflow. I am also loving the day-to-day work of collaborating with my team to solve problems and reach our goals, and have gotten to experience what it is like to be a contributing engineer on a software development team. I couldn't be more grateful and excited to be on this career path!
This past week, I was also given some important feedback on a growth area in my journey. My senior dev talked to me about the fact that it is okay to be "stuck" on a problem for a bit, and that I know enough now to be able to proceed on a ticket without needing to check in or clarify, etc. We also had a great Sprint Retro meeting as a full team (5 of us) where the senior engineers gave us juniors additional feedback that they want us to troubleshoot longer before reaching out and exhaust every option possible, and give lots of context when we do finally reach out. Not only will this help us continue growing and learning, but it helps them on their day-to-day as well because every time one of us asks a question, they are context switching to get up to speed on what we are doing, play around in our draft PR, dig into the code, etc.
Of course, at first I experienced some feelings of insecurity and worry initially after receiving this feedback. "Was I not doing a good job? Was I asking too many questions or silly questions?" But I quickly realized what a great gift this feedback was. Not only did my senior dev feel comfortable enough to say this directly to me, but he also said something very reassuring: "you know enough now to work through problems on your own and complete a ticket without needing to check in." To me, this is a huge sign of trust and faith in me as a software engineer. Even though I am still a junior, this tells me that I am performing well enough and have a solid grasp on our team's goals and project to be able to take a ticket and give it my best shot. Additionally, it tells me that my senior devs don't feel like they need to be looking over my shoulder or breathing down my neck, etc., which as someone who has been a manager before, this is always a good feeling when you can trust the people reporting to you and know their workflow well enough. I am so grateful to have received this feedback, and I was already able to put it into action this past week with the tickets I was working on, as well as when I encountered a blocker.
This life/career lesson also reminded me of an adjacent topic of the difference between single-tasking and multi-tasking. In our society as a whole, we place so much value on productivity and often we are lead to believe that our worth as employees is equivalent to our productivity. But the reality is we are all worth so much more than that, and work output doesn't always tell the full story. Additionally, "productivity" looks different each day and with different people. I realized this week that my instinct to reach out and ask clarifying questions on tickets had more to do with wanting to perform quickly and be as productive as possible in my 3 days a week on the job, than necessarily not knowing where to begin on a ticket or being confused. The reality is that (especially as a software engineer) being stuck can actually be very productive, because it is helping you learn and grow as an engineer. Next time you encounter a similar blocker, you will have that much more debugging and problem analysis experience. Digging into a blocker without reaching out for help is also allowing your team members to have more undivided attention on their tasks as well. Again, I couldn't be more grateful for the amazing team I get to work with during this experience, and for all of the learning and growth I am seeing in myself, both personally and professionally.
- Apprenticeship week 11 focus: Accessibility (Neumeronyms, A11y Project, accomodation categories (physical disabilities, neurodivergence, societal/cultural considerations) accomodation vs. accessibility, standards to measure accessibility (W3C, WAI, SCAG, ARIA, 508 Standards), globalization, internationalization (technical implementation for global needs) and localization (social considerations)
- Accessibility tools: Lighthouse, WAVE web accessibility suite, IBM's Equal Access Checker browser extension for Chrome
- I need to get better at solving algorithms in Javascript instead of Ruby
- Microfrontends
- Working at a large company where you don't always have a lot of "big picture" context
- Django Rest Framework logic for cart and order processing (Fullstack Project)
This week brought to light for me 3 different blindspots within different contexts in my software development journey and apprenticeship: accessibility, Javascript algorithms, and understanding the "big picture" when working at a large company.
Firstly, I am sad to admit that I haven't educated myself very much on accessibility in software development, so this week's lecture was really important for me to gain foundational knowledge on this very important aspect of software development. There were a few snippets about accessibility mentioned during my bootcamp, and that was about it. However beyond that, ultimately it is on me to seek out more learning on this topic. It is actually very ironic that I am a former nonprofit professional who has dedicated years to serving different communities, yet I haven't completely transferred this value into my software development learning yet. It is upsetting to me that only 4% of websites are considered fully accessible, even though it is estimated that 20-70% of the population needs accommodations (and 100% would benefit from these accommodations). I am committing myself to expanding my knowledge in this area through completing a Udemy certification on accessibility as well as implementing accessibility features into our Fullstack Project.
Second, I also realized another area of improvement in my software development journey: solving algorithms in Javascript. I have gotten very comfortable with solving them in Ruby, but have not practiced solving them in Javascript. I realized that I really need to improve this skill, not only for additional tech interviews down the line, but just for my own knowledge improvement in Javascript. I realized this week that when I see a problem in Ruby, I am able to start thinking of the logic and also the structure of setting up the algorithm problem right away. However, I am currently still in a place of panic when I see a Javascript algorithm put in front of me. Even though I am trained in React.js and work in Javascript regularly, for some reason solving these algorithms feels like a completely different skill to me, even though I know they are intertwined. The panic is step 1 that I need to address, which just comes with practice and building up my confidence. I have decided I need to go back to the basics to ramp up this skill and confidence. During my bootcamp, I was given an "algorithm ladder" Trello board that separates algorithms by category, starting with very simple problems and then gradually increasing in difficulty. Working through this Trello board really boosted my confidence and skill level solving algorithms in Ruby, and I know that I can get there in Javascript as well. I am going to commit myself to getting back to the basics with working through this board in Javascript. While I don't think it is a realistic goal for me right now to commit to solving problems every day, I do need to add at least one day a week for solo practice. I am going to try to work on a problem or two by myself on Mondays and see how that routine feels and adjust as needed.
Lastly, I had a realization this week about the difference between working at a small company vs. a big company related to understanding the big picture "context" and the "why" behind waht I am doing day-to-day. Booz Allen Hamilton, with over 30,000 employees, is the largest company I have ever worked for by a long shot. Prior to working here, I have been in small nonprofits, mom-and-pop retail businesses and restaurants, and a small community newspaper in rural Minnesota (it did technically have a corporate umbrella, but the office environment and our newspaper was small). I felt the difference between these working environments and Booz Allen right away within my first week, however I was reminded again this week of just how different it is to be working on a very small part of a very large company. Zooming in closer.... what it is like working on one SCRUM team out of a whole research and development department. Zooming in even closer... what it is like working as a part-time apprentice on a 5-person development team. This week with the tickets I was working on, I was struck by the fact that I didn't necessarily have the large picture context and understanding into why I was doing what I was doing. I am very much used to understanding the big picture strategy at my job, even within my specific role.
As it turned out, we had a lunch-and-learn session on Thursday where our Chief Technology Officer gave big picture context on Booz Allen's strategy and organizational structure and how 4CodeLabs fits in. It was exactly what I needed by the end of the week. But even though I definitely walked away with greater context and a better understanding of the big picture, I recognize that there is just a certain element of "the unknown" that I will experience working at bigger companies. It is not necessarily a bad thing, as long as have at least some big picture context, but it is something that is noticeably different. However as was mentioned during the lunch-and-learn, context is valuable for a few reasons: it gives you context on what success looks like, enables you to be a better problem solver, gives you mission understanding, and ultimately enables you to develop and lead with empathy, drive and motivation. At the same time that all of this is true, I understand the benefit of also having a narrower focus on my team's goals and specific tasks, while other people at the company are worrying about and handling the big picture. It allows for a division of labor as well as a clarity of focus without being overwhelmed by contextual details, or getting caught up with spending too much time on understanding the larger strategy when things are constantly changing and pivoting, etc. All of this is to say that I am going to commit myself to keeping the big picture strategy and objectives in mind in my day-to-day work and by asking questions on "why," while also not allowing myself to wory about not having extra context that I don't necessarily need to do my job effectively.
Overall, this has been a week of insights into areas in my journey where I have room to grow and improve that require a bit more attention and intention. :)
- Apprenticeship week 10 focus: Performance and debugging, linters, breakpoints, Read-Evaluate_Print_Loop (REPL), "Black box" debugging, syscalls, benchmarks vs. profiling, flamegraphs, signals vs. noise, the four "Golden Signals" (latency, traffic, errors, saturation)
- Friday Huddle: "Learning on the Job", intelligence, fixed vs. growth mindset, the Dunning-Kruger Effect
- Chrome debugging tools
- The importance of storytelling in software development at a large company
- Backstage plugins
- Started reading about profilers and how I might set one up for my full-stack project: https://jvns.ca/blog/2017/12/17/how-do-ruby---python-profilers-work-/
Reflections - "The difference between a junior and senior software developer is tolerance for chaos."
This week has me reflecting on skill progression, growth and intelligence, learning at every experience level, and the importance of giving yourself grace through it all. We started this week discussing performance and debugging in software development, which is something that excites my nerdy self. In my previous life as a fundraiser, I always enjoyed working in our CRM and creating dashboards that gave us metrics and measured our progress toward our goals. I was borderline obsessive over these tools and loved getting down to the details of tracking our outreach and efforts.
Now, throughout this apprenticeship with Develop Carolina, I have really enjoyed learning about the different ways to track and measure the performance of an app. However, while some of the assignments the past two weeks have given us a taste of the different tools out there to track and monitor performance, I am really excited to gain exposure to these tools and learn these skills on the job. There is only so much that learning/school environments can teach you about software development, and there is much knowledge to be gained on-the-job and in production environments. And then of course, the learning process is continuous and never stops, regardless of your skill level.
To back up a bit -- on Monday, there were a few quotes/thoughts from our discussion that I jotted down and have been reflecting on this week:
- "When all you have is a hammer, everything looks like a nail." Experience teaches you the best tools to use in different scenarios. I immediately morphed this quote in my head to an image of me as a junior engineer taking a hammer to my keyboard to fix things :D
- "You learn more from the things you break than the things going well." When I eagerly asked Alex how he learned so much about performance and monitoring, he told me that aside from work environments, he learned a lot from intentionally breaking his toy projects. The William Faulkner quote came to mind: "In writing, you must kill all your darlings." While I would hate to kill my darlings, it has made me consider how I might attempt to break one of my apps so that I can play around with implementing a monitoring system. This mindset also reminds me of athletic performance. When I compete in jiu jitsu, I almost always learn more from my losses than from my wins, even though the ego may be bruised in the moment.
- "It’s a different skill set to take things away vs. add things." In the career bell curve, early engineers want to build, build, build, but in later years you learn that you need to simplify and edit, edit, edit. I feel this mindset is so applicable to every discipline. As a big fan of Project Runway, the designers are constantly working to refine their final design and edit for a polished, focused look. As a writer, I knew that often "less is more." And my yogi self recognizes that there is so much strength in simplicity and going back to the root of what you are saying/building/doing/learning. (To go even deeper on the yogi thought, there is so much strength in stillness. But that is a different Ted Talk.) This concept also reminded me of a quote by Matthew May: "To attain knowledge, add things every day. To attain wisdom, subtract things every day."
- Every human being has the capacity to grow." See also: The power of the word "yet." And this can look differently for different people, and that's okay. Intelligence comes in many different forms. But everyone has the capacity to grow and change. Often times the most limiting factor is not other people, but yourself and your internal dialogue. What would you say to a friend engaging in negative self talk vs. what do you say to yourself when you engage in negative self talk?
- A fixed mindset is when someone's qualities (good or bad) are static. A growth mindset is the belief that you always have the ability to change and grow with time. This just rings so true for me with my decision to pursue software development in general. I had people doubt my decision and question my abilities. But I believed that I could learn and grow, and here we are. :)
While I obviously have so many thoughts on each of these concepts, I will attempt to streamline and simplify my thinking by saying this week was a big "AHA!" moment for me in regards to my learning journey and skill progression. While Imposter Syndrome tells you that everyone knows so much more than you, the reality is that everyone has knowledge and intelligence, and it is completely unique to each person but equally valuable, even if society tells us otherwise.
I experienced this at my host company first-hand this week when my senior dev told us how he is still learning every day, that he doesn't know everything (contrary to my original impression), and that there are many unknowns that we work through as software engineers at every seniority level. For example, as a team, we pointed a Docker ticket at 5 points, and it ended up being a huge blocker for the whole team, that all 4 of us spent time attempting to debug, that is taking probably over 30+ points worth of time and work. But in our retro meeting, our senior dev simply said that this sort of thing happens, and that it is important to not get frustrated with yourself or start to feel self-conscious about how long a task is taking you, etc. It is all part of the process and especially with software development. He also later talked about how when the junior engineer and I are looking for feedback or are stuck on something, to please push up a draft PR rather than just asking for a meeting first. He said that the first thing he likes to do is pull down a branch and dig in and see for himself what is going on, and sometimes he might be as lost as we are on a bug or issue, so it is hard to give feedback without first understanding the problem yourself. This sort of honesty and humility from a senior leader is so incredible and it makes me feel like the luckiest Dev Carolina intern that there ever was. :) It also reminded me how learning and skill progression is a continuous journey, and that it is important to have grace for yourself throughout all of it.
While this blog post feels a bit unorganized to me and maybe recursive... arguably it is a recursive subject (see what I did there?) and also, I know that I am still digesting these reflections from the week, so I am going to give myself grace. It felt good to put some of these thoughts down and begin to articulate what I am thinking and feeling, even if it is messy and imperfect! (hey -- another life lesson! They just keep on coming! <3)
- Apprenticeship week 9 focus: Monitoring & observability, telemetry (logs, errors, metrics, traces), monitoring tools (log aggregators, error reporting, application performance monitors (APM), and dashboards)
- Develop Carolina's tech talent ecosystem
- Docker images, containers and setup
- Configuration and documentation for keeping a production project up-to-date
- Jenkins & "the pipeline"
- Semantic line breaks: https://sembr.org/
- Django Signals for automatic model creation
- Setting up Google Oauth in a full-stack project
I have been a paid software engineer for about 6 weeks now, and I can honestly say that the job is even better than what I expected.
Prior to working on-the-job as a software engineer, I thought I would be walking into an environment where everyone knows everything, and I would just have to catch up knowledge base wise. I was so nervous about not knowing all of the answers. But the truth is, no one knows all of the answers. What is more important than knowing every programming language or framework is the skill set of debugging and problem analysis. As I have said in previous posts and especially while working on my full-stack project, I may not have all of the answers or the most experience, but I know how to research and find the answers I need, and I know how to analyze a problem and come up with a solution(s). I think this is definitely my favorite part about being a software engineer that I didn't necessarily expect/anticipate -- that we are all doing so much troubleshooting on a daily basis, regardless of skill or experience level. Every ticket I work on, I am usually working on something I haven't done before, and I am figuring things out, encountering errors and troubleshooting solutions. I love that even the senior developers are doing this as well. It makes me feel empowered that I do know enough to be a junior developer, and that this is a field that I will continue to learn and grow in. It also makes me feel so grateful for the amazing tech mentors I have had throughout my journey so far, who are continuing to help me grow and learn in this process.
The other suprising part about being a software engineer that I didn't expect is just how much collaborative work we are doing every day. Even though I know nearly every work environment has regular meetings and collaborative work and projects, I still had an impression in my mind that I would be interacting with people less as a software engineer. This is something I was actually concerned about because I am someone who enjoys interacting and collaborating with my coworkers, and I wasn't sure if this work environment was going to feel isolating for me. The truth is, we are working closely together every day and communicating almost constantly throughout the day depending on the work involved. Also, the nature of Agile/SCRUM is very team-oriented, goal-oriented and task-oriented, which I love. One aspect about Agile that has particularly been a very positive experience is our retro meetings. While I am not sure that every SCRUM team does this, our team has a part of our retros that involve team shoutouts. So not only are we already feeling good with how much we accomplished throughout the sprint, but we are able to give kudos to our team members and bond in that way and build trust. It has been a positive space for me to experience positive feedback for my efforts, and also a space where I am able to thank my senior team members and give positive feedback back to them as well. It has also been a space where we can talk openly about what didn't go well throughout the sprint, which is also very important. Overall, I am just so grateful for this experience and as well as the opportunity to be working with such an awesome team at Booz Allen and Dev Carolina.
- Apprenticeship week 8 focus: Cloud engineering (DevOps), CI/CD, pair programming on algorithm problems (I'm a little rusty!), and Friday Huddle focus on giving and receiving feedback
- Skeleton directories :D
- The process of ramping up as a team on a new project at work: research, tutorials, coding practice, etc.
- Backstage
- The art and science of asking questions!
- Time management
- Unit testing (Arrange, Act, Assert) with Jest, CVE's and Grype scans, and other cleanup tasks to prepare a project for deployment and tie a nice bow on it
- Apprenticeship week 7 focus: software infrastructure & the cloud, backing services, Iaas, Paas and Saas. "Most cloud costs/workload come down to this... 'How much do I want to manage on my own?'" and Friday huddle focus on communication
- Fullstack project: The many quirks of Django Rest Framework - virtual environment, models&serializers&views...OH-MY!, pycache (grrrr!) and making an extensive .gitignore file (lol)
- Getting more and more comfortable with the Github PR process at work
- It's so important not to compare yourself to others <3 We are all different people on our own learning journeys!
This week's Friday huddle as well as the tasks completed at my work environment had me reflecting a lot about communication. One thing that has been an unexpected realization so far in this experience is that so much of the job of a software engineer revolves around planning and team communication. The life of a software engineer is not a siloed experience where you are writing code by yourself all day, especially with an Agile/SCRUM project management framework. There are many meetings that take place to plan, organize, strategize and decompose large problems into smaller ones, or large projects into bite-sized pieces. At a company, senior developers are in even more meetings than the junior developers, working with other departments and leaders to understand the bigger picture and value proposition of the software development work. I see how much time my tech lead spends just setting up the team for success by providing resources, detailed instructions and information on each story ticket, as well as being very responsive in Slack chat to answer questions and help out when issues arise. All of this is to say, I am learning more and more each week what the on-the-job experience of a developer is like and just how much communication is (arguably) a bigger and more important part of the job than the actual coding of a project.
I am someone who has always prided myself on being a good communicator and I have always enjoyed the process of communicating via writing in particular, which is why I started my career in journalism. This week, I have been drawing paralells between communication via the English language/interpersonal communication to how coding itself is essentially communication with a computer. Additionally, the fact that a large growing segment in software development is centered around prompt engineering demonstrates this parallel even more. With prompt engineering, we are studying and learning the best way to communicate with AI to get the information we want. More and more, I am using AI as a great tool for helping troubleshoot, find resources and speed up the software development process with repetitive code.
I also had a realization this week that effective interpersonal communication is a lot like unit testing! When you write a unit test, you essentially reverse engineer a problem and deconstruct it into smaller parts. You are checking, "this is what SHOULD be happening. Is that what is actually happening?" When communicating with someone effectively, it is important to ask for feedback and ensure your intended message is getting across and is being received accurately. When you write a unit test, there are three parts to it: arrange, act and assert. Arrange is the setup, act is the meat of the logic of what is happening, and assert is confirming that something is doing what is expected. Similarly, it is important when communicating to effectively provide context, directly communicate your message, and then solicit some sort of feedback on that message.
Additionally, on a more detailed level, there are a few specific similarities I have noticed between unit testing and communication. First, clarity. Both require clear and concise language in order to receive positive results. Second, error detection. Just like a unit test can tell you whether or not something is working, effective communication can help uncover misunderstandings. Both provide necessary feedback and information for correction, adjustments and learning. Both also bring about overal quality assurance. Effective communication can foster positive relationships, enhance productivity on teams, and minimize misunderstandings or miscommunications. Similarly, unit testing helps ensure the functionality and reliability of your code, ensuring you can deliver a quality product to users or clients. Lastly... both can be very challenging but also very rewarding. :)
- Django/Python, Next.js and Mantine (initial commit completed for our Fullstack Project!)
- Deeper understanding of schema creation with https://dbdiagram.io/home
- Apprenticeship week 6 focus: software architecture patterns (monolith, service-oriented architecture(SOA), serverless, microservices)
This week at at Booz Allen, I am proud to say I made my first pull request (PR)! :) It was a ticket estimated at 1 story point in Agile terms and involved updating the README file in our project so that the installation instructions were correct. I reviewed the "git workflow" guidelines at BAH, and then reviewed them again, and then again as I completed this ticket with extreme caution on my own git branch. Making a new branch and going through this process with git (something familiar that I have done many times before) was all of the sudden a very nerve-wracking task. It was also absolutely thrilling. My manager reviwed the PR and approved it, and then I got to merge the change into the project myself (omg!!).
Even though this was a simple story, it was still very exciting to be able to make a pull request contribution to my team's project, and it was a very exciting milestone in my journey as a software developer. I started off this week with a lot of feelings of discomfort and unease, specifically around not feeling like I was doing enough or contributing enough to the team's goals. So much of my time up until this point had been spent completing trainings or getting up to speed with our project and setting up my development environments. I was starting to feel self-conscious about not contributing more... I was doubting my abilities and unsure if I was meeting expectations.
Then Wednesday came along. The start of a new Sprint, with a stack of approachable tickets that needed to get done to wrap up our project and finalize it before we move on to something greenfield. I not only was able to make one PR request, but 5 this week!
The process of taking tickets and working to complete them, even though they were small tasks this week, was very rewarding and made me feel productive. As a task-oriented person, I really love the system of Agile and SCRUM for this reason. I also loved feeling like I was a contributing member of the team. Even though I have only been at Booz Allen for 3 weeks, I feel I have learned so much about what it is like to be a software engineer on the day-to-day already. I am realizing that experience really is the best teacher, and I am so grateful to have an on-the-job learning experience like this at a company. I can already tell that my skills with debugging, figuring out unkown technologies and tools, researching and asking well-formulated questions is improving. I am also gaining confidence even just in how I go about asking questions. In previous weeks, I felt the need to DM my manager. But now, I am confident enough to post my questions directly in my team's Slack chat, which is recommended.
Also prior to this experience, I was somewhat resistant to taking on new technologies. I was comfortable building in Ruby on Rails and React, and I wanted to stay in that comfort zone and continue to improve in these two lanes. While this is not a bad strategy, I recognize now that I was not confident in myself and that is what was holding me back. While I had learned a ton in bootcamp about building, I always felt I lacked more of the contextual "big picture" knowledge that computer sicence grads had. However now, even just 3 weeks into this job and 6 weeks into the apprenticeship as a whole, I have gained a lot of confidence with taking on new technologies that are entirely new to me, and I can tell my "big picture" knowledge is expanding with each workshop topic. I am in a space of learning every day both in the classroom and on-the-job. At Booz Allen, I am definitely getting more comfortable in my work environment, but I am also still very much in a place of discomfort, where I am often unsure and just troubleshooting and figuring things out (aka a space of learning and growth, which is good, even though sometimes uncomfortable). With my fullstack project, I intentionally wanted to build in something other than Ruby on Rails so that I could learn and experience a new backend technology. I read some docs and worked through pieces of tutorials on Django/Python, but ultimately decided that I know enough to start building, and can continue to learn as I go. I am really proud of myself for this and am excited to continue learning along with my partner as we build our Food Connect app.
Throughout this apprenticeship, I have continued to hear the phrase repeated that "this is a safe place to fail." While that mindset is hard to embrace wholeheartedly when I am trying to do a good job and land a full-time gig, I really felt it this week throughout the Git/Github work flow at BAH. For example, I made a couple of mistakes in one of my PR requests. When my senior dev reviewed it, he simply explained to me the errors and asked me to correct them. No irreversable damage to the project or interruption of anyone's day because I made a mistake, etc. I simply just took the feedback and was able to make the correction and learn from it. No big deal. And regarding my anxieties earlier in the week about not doing enough/not knowing if I am meeting expectations, both of my mentors simply reminded me that there are virtually ZERO expectations for the apprentices. We are here to learn and grow, and there is no pressure to take on more than we can chew, despite the dynamic that hopefully we make a good impression and can be hired on as junior developers at the end of this. It is definitely a good feeling to recognize these things, and I am looking forward to the week ahead. :)
- Intro to prompt engineering
- On-the-job experience and learning with SCRUM and Agile project management
- Apprenticeship week 5 focus: tech stacks, full-stack project planning
- Wrote my first shell script app!
- Began learning Django/Python and Next.js (technologies my partner and I chose for our full-stack project)
Ever since I was a child, I have always maintained a calendar. Something about the process of looking at both the big picture as well as the everyday details has brought a sense of comfort and even (admittedly) joy to me. A month is organized as a table, with 30 or so little squares on a sheet of paper: 7 columns and 5-6 rows, each little blank square just waiting to hold the data for the day. A month completed, simply turn the page... and the sheet is a fresh start, with 12 sheets adding up to a full year. (Is this why I love databases now so much as a software engineer?! Hmmmm...)
What started as a ritual in my early childhood years with fun themed paper calendars, like puppies or my favorite cartoons, eventually evolved into nature scenes and inspirational quotes in my teenage years. By college, I had moved on to the wonderful invention of the iCalendar, which I still maintain to this day. To get even deeper into the day-to-day details of work and school, I also use a paper planner to manage my daily and weekly tasks and deadlines.
It was no surprise to me that when I completed the DISC Assessment in 2021, my top behavioral style was "the organized work style." Of course! Thorough and systematic, this behavioral style is energized by logical thinking and processes, has a direct communication style, and focuses on being measured, systematic and thorough. This top work style combined with my other top work styles (analysis, persistence, and competitiveness) gave me even deeper insight into the unique skill set I bring to my work, as well as the potential blind spots I should look out for.
Lately, now that I am 6 weeks into the software engineering apprenticeship with 3 weeks of on-the-job experience at Booz Allen, I have been reflecting on how I wish I had found this career path sooner in my life. In hindsight, it seems I have always been suited to a career like software engineering, which satisfies my desire to organize and analyze and also directly challenges me and offers unlimited potential to continue learning and growing. Even the project management style of Agile and SCRUM feels like it is exactly what I want as far as workflow management and organization.
Even though I have been having these feelings lately, I have also observed how my chosen career path up until this point has made complete sense. I have always been drawn to writing ever since I was a kid, which is a kind of hard and soft skill. Something about the combined use of creativity and analysis, challenge as well as stepping into a state of "flow", all within an organized structure with rules and guidelines, really appealed to me and brought joy to me. I also enjoyed the process of communicating something new or something useful... offering a different perspective on a topic or issue, or simply relaying important information. I followed this writing and communication path and started my career in journalism. From there, I made my way into nonprofit marketing, fundraising and grant writing (with a slight detour along the way into sustainable agriculture :)).
In these roles, however, especially in the nonprofit sector, I found myself craving work that was more technical. The parts of my job that I enjoyed the most were working in our CRM or WordPress website or writing a detailed grant proposal. After seeing snippets of HTML and CSS while working in WordPress, I knew I needed to dig deeper and learn more. Around the same time I began researching software development as a career path, I also met a trans-man who happened to be a software engineer. I really believe that everything happens for a reason, and this interaction was no coincidence as well by allowing me to see myself in this industry someday.
Even though I still have these feelings of wishing I had found software engineering earlier in my life, I know all of my personal and professional experiences have made me the person (and software engineer) that I am today. I have a lot of transferrable skills that I have honed over the course of my life so far that will help make me an excellent individual contributor and team member in this industry: planning/organization, analysis and problem-solving, communication and research, teamwork, collaboration, and persistence. Above all else, I am grateful that my journey led me here, grateful to be in this apprenticeship program, and beyond excited for what is to come, both professionally and personally. :)
- Finished AI Foundational course
- Apprenticeship week 4 focus: tooling & team processes
- First week of work at Booz Allen Hamilton!
This was my first week working on-the-job as a software developer! While I have started many new jobs before throughout my life, this one felt very different. Even though I am a seasoned professional with expertise in my previous career path, which was nonprofit management and marketing/fundraising, in this new role, I am humbled to be back at that beginner/novice level once again. This is both an exciting/freeing place to be as well as a challenging place to be.
We have talked a lot throughout the apprenticeship about the importance of embracing a beginner's mindset. The beginner's mindset refers to "a state of mind where one approaches a task or goal with openness, curiosity, and a willingness to learn." By definition of this mindset, I would argue it is important to maintain this mindset no matter your skill or experience level in any field. In my situation however, I am a true beginner, and I have found that grounding myself in this mindset has helped me approach this new role with more patience and grace for myself. If I am embracing a beginner's mindset, I am free (and even expected) to make mistakes. I am free to ask questions that may be obvious to others... I am free to put aside any sort of ego and just embrace the process of learning.
Alex has been quick to point out that the beginner's mindset is very different from imposter syndrome. By definition, imposter syndrome is "a condition of feeling anxious and not experiencing success internally, despite being high-performing in external, objective ways. People who struggle with imposter syndrome believe that they are undeserving of their achievements and the high esteem in which they are, in fact, generally held. They feel that they aren't as competent or intelligent as others might think — and that soon enough, people will discover the truth about them."
I have been struggling with this ever since I began this journey as a software developer in January 2023. I struggled with it throughout my bootcamp, and I couldn't believe I was chosen to be a Teaching Assistant for the next offering of my bootcamp. Same thing goes for the Develop Carolina program. While I surely know how hard I have worked to get here, and I can see how far I have come and how much I have learned in just one year of studying, there is still a part of me that can't believe I am here, working as a software engineer at Booz Allen Hamilton and pursuing a registered apprenticeship in this subject. When these feelings come up, I have been focusing on running through logic and facts: I am an intelligent, hard working person who deserves to be here. Even though there is a lot that I don't know, there is a lot that I DO know, and I am in the appropriate position for my skill and knowledge level as an entry-level software developer.
After my first week on-the-job, these feelings of insecurity and self-doubt have filled me, and I have experienced this sensation of feeling like I will soon be "discovered" to be a fraud. But when I run through the facts, I can see that I did in fact have an amazing first week with tangible accomplishments. I am lucky to be on an awesome team with great people who were kind and helpful and reassuring...who went out of their way to make me feel comfortable and answer my questions. I made tangible progress on my onboarding tasks, and I am already done with the required AI trainings. I even was able to begin setting up my development environment. One of my co-workers applauded me on being noticeably proactive, which felt good to hear.
When I remind myself of these facts, I can see that I am right where I belong, and everything is going to be okay. I feel I am in a place of not just embracing a beginner's mindset, but also embracing the imposter syndrome as part of the process. Rather than pushing those feelings away, I am letting myself feel those insecurities, and then turning towards them to question and analyze them. As someone who has always struggled with anxiety, I am constantly reminding myself that I am not my thoughts, and this is no exception. :)
- Continued learning with AI Foundational courses (BAH and DataCamp)
- Apprenticeship week 3 focus: agile/scrum, history & development of computer hardware, systems architecture, operating systems and virtualization, history & development of the internet, networking fundamentals
- Full-Stack project pitch of Food Connect!
This week I felt like I had finally adjusted to my new work schedule and routine (hooray!) I was able to get restful sleep each night, and I felt more energized during my workdays. Some things that helped me get here include setting a "bedtime" reminder on my phone so that I can start winding down at night; reading a book each night in bed to stay off of electronics, relax and fall asleep quicker; and staying committed to doing something active and/or outdoors each evening after work. I also found a great playlist on Spotfiy called Focus Flow that plays uptempo instrumental hip hop, and I have found it helps me stay focused during the day, especially when I have a lot of independent work time. Another thing that I have found really helps me is keeping up with a set cleaning schedule so that I can maintain a clean and neat working environment. Both the physical act of cleaning as well as the result of having a cleaner home and (now) work environment definitely reduces stress and anxiety, and helps me feel prepared to take on the week. Sometimes I jokingly call this "anxious cleaning," but even so, it really does work! :)
One concept that really stood out to me this week during our Develop Carolina lectures was this idea of "slack time" during Scrum sprints. "Slack time" refers to deliberately leaving time for unplanned tasks, such as issues/adjustments/pivots/delays, additional training or collaboration time needed, other projects or tasks that come up, etc. We also discussed how no system can operate at full/maximum capacity for a prolonged period of time. This idea applies to machines and it also applies to people! Trying to operate at full capacity is simply not realistic. There are days of high productivity and days where you are simply doing what you can to get through that day, and then everything in between.
This idea of maximizing capacity took me back to my days managing a team at a restaurant. My boss at the time wanted to make staffing cuts for a number of reasons, but one of those was to maximize the remaining staff and keep everyone busy. While this worked when everything was going smoothly and we were at an average level of busyness, it did not account for staff getting sick, taking conflicting vacations, times when we were busier than usual, etc. It actually led to overall stress of the team and burnout. What would have been a smarter way of operating would have been to schedule staff with this concept in mind... that we shouldn't be aiming to max out staff, but we need to be overprepared so that we can be flexible and account for the unplanned.
It also was just a good self-care reminder for me. Even machines can't operate at full capacity for a prolonged period of time, so I should not have that expectation for myself, which sometimes I know I am hard on myself with this. As I begin my first week as a software developer (OMG!!!!) I will be keeping this in mind and trying my best to give myself grace, patience and kindness. My "best" is going to look different each day, and that is okay. I also need to prioritize time to recharge and take care of my physical and mental health as I move through this experience. I am feeling so full of gratitude to have been accepted into this program and selected by Booz Allen for this apprenticeship. I am incredibly nervous and know I am going to face a lot of discomfort throughout the next six months, but as Alex has said, "you should be a little uncomfortable. It means you are in a learning space." :)
- Completed Booz Allen's AI Aware Training & now working through AI Foundational training
- Started AI Foundations via DataCamp as well
- Apprenticeship week 2 focus: team roles as companies grow, management at companies and how software engineers fit in, agile vs. waterfall software development methodologies
- Full-stack project brainstorming. Focus was on aproaching app development from a scientific perspective: problem statement, hypothesis statement, user validation interviews in order to assess P-M-F
- Met both my Develop Carolina mentor and Booz Allen Hamilton mentor! Both are awesome!
In many ways, this experience feels like going back to college (at least for now before I start at Booz Allen) in the sense that I have dedicated class time, and then the rest of my time is independent study time. As someone who enjoys and thrives in structured environments, this has required me to try and establish structure for myself in order to make this new career path sustainable for me, for the next 6 months and beyond.
This week has definitely been a week of adjusting and working through a full range of emotions from insecurity and Imposter Syndrome, anxiety, to excitement, confidence, and calmness. The past year and a half, I have been working a second shift job that was in-person and required me to be on my feet all day and engaging with customers. I knew I would face an adjustment period for going back to a first shift schedule (8-4pm), however I did not anticipate the adjustment I would face for going back to a fully remote environment. While I have worked fully remote before, I haven't done it since 2020/early 2021, and I found myself struggling during independent study with all of the quiet, unstructured alone time, and wishing I could connect with my peers in person. I have discovered a few strategies so far that have been helpful for me in this new environment: setting 1-2 task goals to accomplish each day, whether it is completing a training or making it to a certain chapter/module; focusing solely on Dev Carolina homework, or focusing on coding practice. On a personal level, I have found it is helpful for me to get out of the apartment each evening to workout at the gym, move my body and engage with people in person. I also have enjoyed switching up where I am working remotely from -- on Thursday I was able to work at my partner's place, and on Friday at my parents' place. Having people around me while I am working has even helped boost my productivity I have found. I know once we begin on-the-job work and get deeper into the apprenticeship, there will be a bit more structure in place naturally because there will be more work that needs to be done withn a certain time frame.
Despite my personal challenges through this adjustment, I am absolutely loving the program so far and feel I have learned so much within a short amount of time! We have such a thoughtful and reflective group of apprentices, and Alex and Cara from Dev Carolina are wonderful people and facilitators. It will be really awesome to look back on the past 6 months on how much we have learned and grown. I am practicing patience with myself and trying to be gentle with myself as I make this huge transition. :)
From a content perspective, I am so excited to be learning more about Artificial Intelligence. I am definintely someone who admittedly has had dystopian fears about AI, worried about its impact on society and concerned about the ethics of it. I can already tell my perspective is shifting as I learn more about it, and I am comforted by the fact that ethical AI is a huge topic of discussion and consideration. More to come on my thoughts and learnings on AI.... but I am already thinking about how I might incorporate AI into my full-stack project!
- Started Booz Allen Hamilton's AI Aware Training - basics of artificial intelligence, machine learning and neural networks
- Apprenticeship week 1 focus: craftsmanship, PMF (Product Market Fit), stages of a company, product life-cycle (startup, growth, maturity, renewal/decline), technology adoption life cycle
Prior to Develop Carolina, when I heard the term "apprenticeship," my mind often went to trade career apprenticeships (electrician, plumber, welder, HVAC, etc.) I understood apprenticeships to be on-the-job career training where an employer can pass on knowledge and prepare their future workforce and an apprentice can learn tangible skills in the real world (outside of the classroom). After studying software development and researching job opportunities, I was instantly drawn to this idea of pursuing a software development apprenticeship. Even though I have been studying software development for exactly a year now, I still feel so much like a beginner and a student. I know I have learned a lot and have come a long way, but I still feel so early in my journey and I know I have a lot to learn still and improve upon. I began to seek out apprenticeships in software development as a way to bridge this gap between my student journey and first entry-level job in software engineering. As compared to an internship, apprenticeships feel (to me) like a higher level, more serious opportunity that incorporates both on-the-job training and classroom learning.
To me, this apprenticeship with Develop Carolina and Booz Allen Hamilton is the perfect learning opportunity for me to sharpen my skills and prepare for my first full-time entry-level role in software development. While I have gained valuable tactile learning experience through both my bootcamp and time working as a bootcamp teaching assistant, this feels like an opportunity to really understand what it is like to be a software developer on-the-job. My original assocations with the word "apprenticeship" have now been applied to software development and also expanded to include this idea of "craftsmanship." I love that I will have the opportunity to learn from the senior developers around me as well as my peers through this opportunity and benefit from this "passing on of knowledge." After this week's discussion and reflections on "craftsmanship," I have begun to see software development as a true craft and see this apprenticeship as an opporunity for me to really develop my craft. The fact that coding and software development is a very tangible skill that requires intensive time and training was part of what initially drew me to it, even though I didn't think of it at the time as craftsmanship.
In additon to improving my technical skills and honing my craft, I am also hoping to gain some intangible knowledge/skills on what it is like working as a software engineer as part of a team for a large company like Booz Allen Hamilton. I have also really enjoyed the business-focused discussions we have had this week at Develop Carolina, as I have never formally studied businesses before. I am both excited and nervous about this opportunity and am eager to contribute and perform at Booz Allen Hamilton. I am also thinking way ahead to landing that first entry-level role after the apprenticeship. I know that putting in hard work while also taking things one day at a time with steadiness and perseverence will get me there, but I can't help but think ahead to preparing and planning for that next step!
- First couple of days of my Develop Carolina and Booz Allen Hamilton apprenticeship!
- History and evolution of craftsmanship (survival > innovation > organization > automation)
- Honing your craft as a learner using Alistair Cockburn's ShuHaRi model of mastering a craft:
- Shu (doing what you are told, imitation, directly taught)
- Ha (casual mastery, internalization, still basing work on patterns but now competetent enough to tweak your own, improve existing recipes, defining your practice)
- Ri (true innovation, using all the knowledge you've gained through shu and ha as you create new rules/pathways/techniques and discover new ways of working and new definitions of quality)
- Honing your craft as a mentor. Mentoring someone allows the mentor to practice "ha" and improve your knowledge.
Today in our Develop Carolina apprenticeship we spent time discussing the movie "Jiro Dreams of Sushi" and reflecting on this idea of craftsmanship and being a "shokunin."
We were given a prompt to compare/contrast three different trades using this idea of universal craftsmanship and reflect on how modern mindsets may change ancient patterns. I am choosing cooking/food preparation, writing, and Brazilian jiu jitsu as trades/skills that I am passionate about that have similarities and differences in terms of craftsmanship and their evolutions.
For each of these crafts, a similar mindset is needed in order to be successful. You need to be dedicated to learning and taking in as much content/inspiration/learning material as you can, you need to have an analytical mindset that is focused on improvement, you need to develp a consistent practice, and you need to be patient with yourself throughout the learning process in order to avoid burnout. I think the evolution of craftsmanship can be seen in each of these crafts as well: cooking/food preparation, writing and jiu jitsu all started out of a survival mindset. Finding and preparing food is literally something humans needed to do to survive; writing is something that even in its most primitive form was a means of providing necessary communication and documentation; and jiu jitus at its basic form is a self-defense that was developed so that a smaller person could defend themselves against a larger and stronger opponent.
Over time, each of these crafts have evolved, innovated (and even automated) into what we see today, while the core principles and mindsets can still be seen in the highest quality versions of these crafts. Food preparation has evolved in every culture to achieve the best taste, nutrition and presentation and is a form of artistic expression now, not just survival. Food has also been automated for production, from modern farming practices to fast food restauraunts. Writing has evolved also into a form of artistic expression and different kinds of writing have evolved beyond just the need to communicate in your own native language (computer/software languages were developed!). Today, ChatGPT can be prompted to write resumes, bios and even poems. Jiu jitsu has its origins in 17th century Japan, but in 1914 underwent a siginifcant evolution in Brazil to become what we see today, which is Brazilian Jiu Jitsu. The Brazilians took jiu jitsu, which focused largely on pins, joint locks and throws, and focused it more heavily on ground fighting and grappling as well as the competition/sport aspect of it.
In each of these three trades, we can see the pros and cons of evolution and innovation. I could write an entire separate blog post about the pros and cons of each of these, but I will say briefly that while innovation is usually a positive thing and based on a societal need, there is almost always a trade off or downside. While modern farming and food production practices have allowed us to produce more food and feed more people and provide more jobs, a lot of quality and even nutrition is lost, and I think modern society today is very disconnected with where their food comes from and how it's grown. Today, many people are using ChatGPT and AI to craft their resumes, write papers and more. While there is a conveneice to that, and it might save time or give someone a jump start on developing those things, I think a lot of the human creativity, connection and learning is lost, and I am skeptical (and also terrified) of AI being able to replicate human creativity. There is a lot to be gained from writing on your own and using your own creativity and analysis to produce something. Lastly, Brazilian jiu jitsu was originally coined the "gentle art" for its focus on using your opponent's energy against them and was very approachable for everyone to learn. However Brazilian jiu jitsu today can be seen as very aggressive and feels very much like fighting, despite the new techniques and positive innovations we have seen in the martial art and sport.
Lastly, these reflections on craftsmanship can be applied to my journey as a software developer. For me, I am working hard in the "Shu" space (the shoebox, as Alex calls it, lol!) and into the "Ha" space as well... not quite there yet as far as "Ri!" My focus for success in this craft is on these five things: consistency, problem-solving mindset, collaboration, patience and practice. The software development field has evolved and seen some huge innovations, and it is a field that will continue to grow and change quickly. This is something that is nerve-wracking, but ultimately I am excited to be in a field that will require me to constantly learn and grow -- it is what drew me to software development to begin with!
- Flask tutorial and basic Python
- Creating a Ruby API backend with Sinatra
- Vue tutorial
- More progress on my Cheers! app frontend using React.js
This week I was reminded of how much there is to learn when it comes to web development, and how as you learn new technologies, you need to continue revisiting & relearning previous technologies. I have enjoyed working in Ruby this summer (on my Cheers! app as well as helping students learn Ruby at Actualize), however found myself needing a refresher once I started working in React.js again the past couple of weeks. It is a good reminder that just like with any new skill, you need to continue to revisit information over and over again to commit it to permanent memory. I made great progress with my Cheers! app frontend as a single-page application and now need to break it into separate pages, add styling, and play around with Mapbox, which will be a new technology for me. I am also looking forward to spending more time practicing algorithms so that I am prepared for technical interviews.
- Rails API CRUD practice with Cheers! App I am building (Ruby backend, React frontend)
- Ingesting data into Database using a call to an external API
- Exploration of Mapbox API
- First few weeks of being an Actualize Teaching Assistant!
- First few weeks of code mentorship program!
It has been a while since I have written in my journal but my web dev learning journey continues! Following my Actualize bootcamp, I was really excited to interivew for & be offered a Teaching Assistant position with Actualize. Now, I am one of two Teaching Assistants with the Summer 2023 day-time cohort, The Starship Loopers. :) It has been a great experience so far not only being able to support students through the material, but to see their own growth and "aha!" moments. It is the same gratification I have gotten from coaching sports over the years. It is crazy to think we are only 3 weeks into the bootcamp and I can already see people getting more comfortable with each other and more confident in their coding skills. I have also enjoyed being around the material and the "re-learning" process. Just like any new skill or activity, the more you are able to re-visit and re-learn, the more the material sinks in and you pick up on additional details you may not have seen or understood the first time around.
Additionally, through Actualize's Tech Mentorship program, I am super excited to have been paired up with a tech mentor who is currently working in the field! My tech mentor, Helena, not only is LGBTQ+ like me, but is currently programming in Ruby and React for her job. It has felt like a really great fit not only personally but professionally as far as having someone there to ask questions about current projects I am working on or questions about what it is like being a web developer, etc.
The past couple of weeks I have been focusing largely on my Cheers! brewery-sharing app. I am building it with a Ruby backend and React frontend. Using data sourced from Open Brewery DB that I seeded into my database, the current version of the app allows a user to sign up, login, view all breweries, view specific breweries, and CRUD a "checkin" to each brewery. I just finished up the backend today and am looking forward to working on the frontend and incorporating geolocation functionality using Mapbox.
- I loved the lessons in pre-work and it gave me a solid foundation entering this course
- My favorite overall exercises were the project-building in both Ruby and React.js (individual and team projects). I have loved the detail-oriented work of figuring out the functionality of building an app and building basic CRUD actions. While I have not enjoyed the styling & design part of web development as much, I hope that it grows on me a bit with time.
- Spending time understanding databases inlcluding: associations, normalization and basic SQL
- API authentication and user logins
- I really enjoyed working in React.js to create a functioning front-end, learning Javascript syntax, and all of the small extra details you can do to customize and improve the front-end experience for a user.
I am so grateful that I decided to take this step and enroll in Actualize, and I am super proud of everything I have accomplished even though I know I still have so much more to learn. I had been curious about learning coding for about a year but was unsure of myself before I finally took the step to go through a bootcamp. I am excited to have found a career path that I know will keep me very engaged and will hopefully be very fulfilling, especially if I can find a career that combines web development with social impact.
Although we moved very quickly through a lot of content in this course, I feel I have a solid foundation because of the curriculum Actualize has developed and because of our lead instructor. I personally am really sad that the course is ending and will really miss everyone in this class because I feel like we have gotten to know each other well and spent so much time together the past few months. Some of the skills & lessons I have developed here that I feel will help me as I navigate my career:
- Not being afraid of breaking things and receiving error messages. :)
- Google is your friend!!
- Being able to decompose a problem that I have never solved before and break it into smaller pieces or logically talk through some ways I might tackle a problem. Even when a problem has been too advanced for where I am at in my learning journey, there is usually at least some start of analyzing the problem that you can accomplish.
- Being able to work on a coding project collaboratively as part of a team and create a finished product together.
- A solid understanding of big-picture web development concepts that I can continue to build upon as I learn new skills and technologies
- The importance of making an MVP first before making it an ideal app (make it work, then make it cute!) :)
- The self-confidence to keep learning and trying new things even if I "fail" :)
- Seeding a database by reading a CSV file
- Lots of practice with database migrations in rails!
- React does not like to display boolean data
- Conditional rendering in React
- The complexities of search bars -- the functionality is way more complex than I originally thought!
- An overall deeper understanding of creating a full-stack app using Ruby on Rails and React.js
- Time management lessons learned when taking on indepth projects
While my project is still very much a work-in-progress, I am really proud of the version 1 app I was able to create. A big takeaway for me in going through this process was time management and prioritzation of tasks based on what is needed to create a MVP (minimum viable product) vs. what is extra functionality that I hope the app can have. For example, because I enjoy databases and working with data, I spent quite a bit of time trying to find an API that would allow me to access a large amount of hiking trail data. At one point, I attempted to web-scrape AllTrails myself however that was going to be a project in and of itself. Eventually, I seeded my database with a CSV of trail data, however I realized I would need to manually add in park_id codes because parks and hikes were assocated in my database models. The takeaway here is that even though it was exciting to me to get the data that I wanted, that ultimately wasn't the most important part about this project.
Another example of this was that I spent a decent amount of time trying to implement a more complex search bar that would not just filter through the hike or park index, but rather allow a user to search for a hike by the city or zip code they are in. After following a tutorial and reading multiple code sources online, I decided to resort to the most basic search bar I could create. I think the takeaway here is again, to prioritize creating the most basic functionality for the MVP before implementing something more complex. Before this project, I did not realize how complex search bars can be especially when you have a database with multiple tables. I look forward to tackling this at a later time because the search bar is really the biggest functionality piece of this app that would set it apart.
Lastly, while I am not very inclined toward design, I wish I would have budgeted more time to spend on designing this application. Right now, I have a very basic bootstrap navigation bar and that is about it. I originally wanted to look into importing a theme into this app so that I wouldn't have to manually design the app myself. This is another piece I look forward to completing in the near future that is an important part of polishing an MVP for presentation to others.
Overall, going through this process gave me a better understanding of project management in general for coding projects. While I created a chart for my project stories & models that outlined by MVP, next time I would like to make an even more detailed version of this broken down by task so that I can better manage my time when creating minimum functionality.
- 3rd party React libraries
- Hiding API keys
- An overview of SQL
- Ruby Active Record Querying
- .limit and .offset
- Rails N + 1 problem and .includes
My favorite part of this week was working on partner projects to mimic working at a company on a client project. On Thursday this week, my project partner Anna and I started following a tutorial to build a clone of the online game "Wordle" using React. While there were definitley a lot of things in the tutorial that were more complex than we had learned up until this point, I felt it was very helpful to work through a tutorial step-by-step to build the app, and with each project (no matter the size/complexity) I feel more knowledgeable and experienced.
On Friday, we were surprised to hear we would be switching projects and partners. Neil and I were partnered up and inherited someone else's code for an app where a user enters an address and the app shows them the five closest supermarket locations to that address using a dataset. It was challenging to inherit someone else's code because it required trying to get into the mind of another developer and their thought process. Rather than scrapping the existing code, we decided to procede with what had already been started, however we spent a lot of time researching available map API's that didn't require credit card information. Ultimately, I decided to sign up for a Mapbox account so that we could implement this feature into our app, however we ran out of time to work through the tutorial to completion. I felt disappointed that we weren't able to finish in time, but I am looking forward to working on this project at a later date now that I have researched different ways you can go about completing it and found some helpful resources.
I think the biggest challenge for me in this cohort has just been juggling the intensity of how much material we are learning with other commitments going on in my life. We have covered a ton of material in a very short amount of time, and while I am proud of how far I have come in my web dev journey, I recognize how much further I have to go, and I am hungry for more knowledge and experience so I can continue to improve my skills. After this week, I have a better understanding of the kind of projects I want to display in my portfolio and have two new in-progress projects. I definitely have a lot of independent work to get done that requires more time outside of class, but I am excited to complete these projects and learn more about React and implementing mapping APIs.
- Building a frontend from scratch in React & connecting it with a Ruby backend
- HTML Forms in React
- React "hooks" useState and useEffect
- Routing in React with multiple pages
- Extra Javascript libraries & logic including controlled forms, error messages for status codes, conditional rendering, search filters and flash messages
I am really enjoying learning how to build out a frontend in React and connecting it to a backend. The Javascript syntax can be tricky sometimes with the punctuation, but I am enjoying learning the logic behind building a frontend from scratch and would like to spend more time working with React and Javascript. I am a little confused on the useEffect hook in React and how it functions and will be researching this a bit to get a better handle on this concept. This week, we also spent time working on "take-home" assignments for interview prep. It made me realize that I need to brush up on Object-Oriented Programming since it has been a while since we have practiced doing that.
I have my first informational interview planned on Monday next week with an acquaintence who is a tech professional. I am really looking forward to asking him more questions about his experience and journey as a web development professional. I would love to connect with other bootcamp grads who have changed careers from a similar path.
I can't believe we are about a month away from this class ending. I honestly am feeling that I wish it was longer because I have really enjoyed it! If I were to give advise to my past self, it would be to not overthink my projects. During both the passion projects and individual projects, I got a little hung up on certain details or wanting to do things the long way to understand the full process, but now I feel a bit behind on my portfolio. I also would tell myself to carve out more time for deliberate practice with algorithm challenges, although I am proud of everything that I have been juggling between this class, work, my board service with the LGBTQ+ Center and organizing our 3rd annual PrideFest. Overall, I am feeling eager to continue to learn and expand my knowledge in web development and have had a really positive experience in this bootcamp!
- Basics of creating a frontend using React!
- More practice with Bootstrap, Javascript & CSS
- Fun coding practice with HackerRank! https://www.hackerrank.com
This week we started learning React and I am really enjoying it! It's pretty cool that React is able to handle HTML inside its own Javascript files. We practiced using a Ruby on Rails backend and started our frontend in React by creating all of the functions (or "Components") in app.jsx for all elements of the website. We then split them all out into separate files, creating a "tree-like" structure with parent components and children components. We also used basic "hook" functions like useState and useEffect to load and display our content the way we wanted it to. I think I am doing well understanding the concepts of functionality in React and how things connect, but I am still getting used to the syntax of Javascript, HTML and CSS. I'm looking forward to practicing more with these languages and using React to build a frontend.
I met with our career advisor this week to go over my initial resume draft. I am feeling a bit behind on my portfolio projects and want to polish them more before I start applying to jobs. Our career advisor had a good piece of advise on this, though. She said to make a list of all of the things that are in progress or being refactored under the Projects section of my resume, because there will always be improvements you want to make to your projects, so that shouldn't deter you from applying for jobs. After spending more time working on bootstrap and the design part of coding, I am realizing that I am more interested in functionality than design and am not super interested in being a designer! When I started this bootcamp I thought I would want to pursue a career in frontend development and now I am leaning more towards backend development. In general, I still feel very much like a beginner in web development but I know with time I will become more confident in my skills with additional experience. I think my first entry-level development job will be a period of huge growth as I am able to learn on-the-job and learn from more senior developers on the team. I am really looking forward to the team environment of working in a development department!
- vanilla HTML, CSS and Javascript
- implementing HTML/CSS/JS features into a website
- More practice solving algorithms during pair whiteboarding time
- Tech job boards & job-search expectations
We started this week diving into some of the basics of HTML, CSS and Javascript and how you can build features like mobile menus and sign-up modules into a website using all three. A great metaphor our teacher used to describe these three elements is to think of them as a body: the HTML is the skeleton of the website (structure), CSS is the skin/style (colors/fonts, etc), and Javascript is the muscles (functionality and responsiveness). As a side note, I was really excited to read about accessibility design for websites. This includes writing good HTML and CSS code so that your website is accessible for people with disabilities, those using mobile devices and those with slow network connections. I am interested in learning more about careers that focus on this kind of coding and think it might be a career path I would find fulfilling.
Speaking of career paths -- this week we also spent time preparing for the upcoming tech job-search. This is both nerve-wracking and exciting for me. I am confident that I can learn any skill on-the-job, but the process of applying and interviewing for jobs has always been very stressful for me, and I am especially nervous to go through this process in a new field. We spent time preparing our resumes, learning about different career options, and discussing expectations regarding the job-search process. Although I will not be too picky when trying to find my first job in tech, right now I am interested in learning about these career path options: accessibility web development, back-end development, testing/quality assurance, and databse administration.
We also spent time "whiteboarding" in pairs this week, where we each practice solving an algorithm as if it were an interview question. It was a good reminder of how important deliberate practice is, so that even when I am nervous in an interview, I am as prepared as I possibly can be to work through these problems without issue. I think above all else, it is really important to try and stay calm while in these high-pressure situations and keep a positive attitude. I have not been the strongest with whiteboarding this week, but I know that is not due to any inability on my end but more to do with the fact that I have only been learning coding for a few months and I am still learning the material. I also have been juggling multiple things in my life and need to carve out more time for my deliberate practice. In addition to increasing my deliberate practice time, spending more time polishing my projects (including version 2 of my Untappd clone) and creating my personal website will help me feel more prepared for the job search ahead.
- Accessibility: https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility
- CSS CheatSheet: https://htmlcheatsheet.com/css/
- Leet Code for deliberate practice: https://leetcode.com/problemset/all/
- Tech Jobs for Good: https://techjobsforgood.com
- BuiltinCHI job board: https://www.builtinchicago.org
- All Hands job board: https://www.all-hands.us
- Javascript basics
- Modern Javascript
- More practice building a full-stack Rails app
- Ruby on Rails forms
We started this week by working on individual projects, and I chose to make a clone of the app Untappd, which is a popular beer rating mobile app. I decided to do this using Ruby on Rails in order to get more practice with the skills we have been working on in this language and framework. I started the project by decomposing the problem and making a chart of all of the pieces that needed to get done including making a chart of all of the user stories and database models. While I did not finish the project completely, I feel that I gained a better understanding of all of the moving pieces and interconnection witin a full stack application. I struggled quite a bit working through creating forms in the app and I did not get a chance to incorporate front-end design. I am planning on making a "version 2" of this app for my portfolio and am excited to give it another shot.
One thing I am realizing is that the more I learn about coding and web development, the more I see how much more information there is out there to learn. It can be very overwhelming and I am realizing that it is important to approach this work with curiosity, persistence and patience and not give in to feeling anxious about it. I ordered a couple of beginner web dev books that will be arriving this weekend and I am excited to start taking a deeper dive into web development from a conceptual perspective. Additionally, I want to continue to work on building more projects in order to feel more confident in my skills.
- Creating full-stack apps in Ruby on Rails
- Basics of Bootstrap
- Writing HTML and Ruby in ERB (Embedded Ruby) view files
- GitHub branching for team projects
I really enjoyed seeing and understanding the "big picture" when building a full-stack app in Rails. It is super empowering to be able to build functionality and styling throughout a website and I am looking forward to practicing building more full-stack applications. We had our first team project this week and my group built a job board. I think we did a great job of decomposing the project into smaller pieces, splitting up the work, and collaborating on some of the tougher areas of the project. Sometimes, it is helpful to just talk things out with a partner in order to troubleshoot the problem together. I felt confident working on the code for the backend of the app, however working on the frontend was challenging for me as I do not have prior experience with Bootstrap, HTML/CSS and writing code for the ERB view files. I found myself getting very overwhelmed and needing to go back to the user guides to just better understand the basic syntax of the code and understand how things worked together. Once I was able to get a better handle on that, I was able to tinker around and figure things out with writing code for the frontend of our job board and individual job listings.
Last week, I was feeling very overwhelemed and frustrated with my blood bank database project. I was anxious to start building the functionality, but was overwhelmed by the many different ways to go about starting the project, the mass of information available to me on the internet, and the more technical "computer science" steps I needed to take to start the project. After talking with my bootcamp instructor, Amanda, she told me to "build the skateboard before the rocketship." It was a great reminder that you need to do the small projects first not only to grow your knowledge base but to have those "small wins" that give you that sense of accomplishment and push to keep moving forward. I know I can build the bloodbank database someday but I need to work on some smaller projects right now as a beginner developer. One of my teammates, Lucero, had a great resource for keeping up with deliberate practice and learning new languages: https://exercism.org/. I am interested in learning and practicing SQL and Python in addition to more practice with Ruby on Rails.
- Building databases using Ruby on Rails
- Different kinds of params (url segment, query and body params) to take in input from a user
- Database migrations
- Validations
- Database normalization
- Hashing passwords & API authentication
I made some progress in my Blood Bank Database project. After doing some research, I downloaded mySQL Workbench to help me build out my databse. I learned there are a few different ways to create a databse in MySQL: using mySQL Workbench GUI, writing a MySQL Query segment, and lastly from the command line in your terminal. I built out 8 tables in my database using the Workbench GUI but I would like to play around with doing this work from the terminal instead. I am trying to figure out how to input data into my tables now. I would love to figure out a way to creatively display this work in my portfolio when I am finished.
- This week we talked about how our prior experiences (both personal and professional) can lend themselves to our journey in tech. One thing I have been thinking about is how my experience learning jiu jitsu is applicable to learning tech. Over the last 4+ years of studying this martial art, I have learned that persistence and patience are key. There is a metaphor we use in jiu jitsu about your learning journey being like an empty bucket, and every time you practice it is a drop in the bucket. On the day-to-day, it can be hard to see the progress and there are sometimes frustrations, but if you stick with it and trust the process, you will improve. It is really exciting and empowering to me to see how I have improved and deepened my understanding of programming concepts in just the past 3 weeks of this cohort.
- This week involved a lot of pair programming where we worked through problems in groups of two. It was helpful to have another person to troubleshoot problems with but also very helpful to look at someone else's code and try and walk them through how to fix an error. As a team we were challenged to use logic to simplify the problem and then debug.
This week was very exciting because we learned how to build our own API using Ruby on Rails. I definitely have gained a better understanding of back-end framework after this week. We practiced making sample apps where we focused on creating routes, controllers and actions. We also practiced creating and seeding a databse in Ruby Rails and learned basic web requests.
We started talking about our passion projects and I expressed interest in learning SQL because I enjoy working in databases. After playing around with a SQL game for beginners, I decided I would like to create a blood bank donorbase for my passion project. This will involve storing interrelated data on patients, blood donors and blood banks. I downloaded MySQL to start, but am not sure where to begin with this project. I am looking forward to beginning next week.
Lastly, I am still adjusting to my new school & work schedule, and am trying to find a schedule for my deliberate practice so that I can keep improving my skills. Overall, I am loving class so far and am looking forward to continuing to learn more!
- https://mystery.knightlab.com - a very fun game to learn basic SQL concepts and commands!
- Web request image
This week involved lots of practice with writing the basics of Ruby code. I learned about Git and Github for the first time.
- Something I am struggling with this week is the concept of API's and back-end framework. This is all so new to me!
- Something I have gotten better at this week is basic coding skills!