This Dot Blog
This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.
Leveling Up Your Work Through Architecture Design and Time Estimation
> This post can be useful for developers at any level! However, it is written mostly for entry-level developers who are starting to transition into a more intermediate role. You’re rocking your first development job. You’re completing tasks, the team loves you, you still have tons of questions but you can get answers and build what you’re asked to build. But you want to keep improving your skills and giving yourself more options. Some of that skill can only come from actually building things over time. But surely there’s something you can do to level up besides that, right? There is! One way to help deepen your understanding of the software you’re writing and make yourself look more impressive is by improving your ability to estimate your time, and how you talk about your work. That’s what we’re going to dig into today! Some terminology You might have heard of, or have read terms like “software architecture” and “quality attributes” and, upon trying to look into them, been met with a LOT of jargon and dense terminology. So before we get too far into this, let’s go over a few terms we’ll use. (This is by no means meant to be a complete description of these terms. The aim is to be clear enough to continue our discussion here, and let you get started.) - Software architecture: This term means how your system is organized. It’s like the blueprint for the application or website you’re building. How do all the pieces we build fit together and interact with each other? What’s the main goal we’re trying to achieve with this codebase? That’s what this term is talking about. - Software design: Once we have the blueprint, we need to figure out how to build the pieces to make that structure come to life. This is where the design comes in. It’s more code-specific and focuses more on the specifics of what we need to build and how. What languages are we using? How do we get this component to be interactive or usable like we want? This is all the design. - Software quality attributes: Sometimes referred to as “ilities” because a lot of them end with those letters, these are words we use to describe the software we write. Common ones would be accessibility, reliability, or performance. These are words used to describe some of the key qualities we want our software to have. You can start with this list of quality attributes or do a search for “software quality attributes”, and find all sorts of articles covering a lot of the common ones. - Time estimation: This is the skill of being able to consider a task and estimate how long it would take you to complete the task. Time can be a funny thing, and it’s pretty common to think something will be easy and have it take way longer, or think something will be complex, and it turns out to be straightforward. - Trade-offs: This is the idea that two things can’t be equally balanced and/or important. There’s a joke about how people want things fast, cheap, and good and you can’t have all three. This is the same idea. Very often, by increasing one quality, you have to decrease another. The balance of those, and the choice to focus on one quality more than another, is called a trade-off. You’re trading the strength of one quality for another. When we’re using the phrase “architecture design” in this article, we’re combining all these concepts together. How do we get started? Ok, so we’ve got some terms now. But what do we do with them? How do we get better at designing software, and estimating our time? I’ve got two templates to share with you that can help you start to develop these skills. Both will involve writing, but I’ve tried to make them as straightforward to fill out as possible so it’s not a chore to use them. I’ll share links for the templates later on. But first, we’ll go over the actual contents of both of them and talk about how to use them. These templates can be useful for any task, no matter how complex. However, super simple tasks like fixing a broken link on a page, or adjusting a color value to improve its contrast may not be the best choice for it. It is useful to use this template on a task that you fully understand, so you get some practice with thinking about the tradeoffs you’re making, and get used to some of the terminology and how to talk about the software you build. But this can really help when you start getting larger tasks or features- ones that might contain multiple parts working together or some complex logic to get the task working properly. The architecture design template For this template, the goal is to complete this first before you do any work on your task. Use this as a tool to help you think through your work before you get started on it so you can have a better understanding of what the task is asking of you, and let you start thinking about the attributes you’re building for. There are 7 sections for this document, each with a title and description. Let’s go over each piece to see how they work. Big picture: What’s the ask? *What’s the ticket/task trying to solve? What’s the end goal of this body of work? Describe the problem in the most ELI5 way you can.* Use this section to describe the task you’re working on. Act like you’re talking to someone with very little understanding of the situation, like a project manager on another team or to a friend of yours that doesn’t work with you. This section helps you make sure you have a strong handle on the work you’re being asked to do, and what the end result should be. Requirements *Is there acceptance criteria? A specific way it needs to work? What makes this ticket / task count as complete? Steps to reproduce and/or screenshots are helpful here too, if available.* Some of this can often be copied over from the ticket you’re working on. Make note of how you can tell that this task is complete, and any specifics that you need to make sure work as expected when you’re ready to have someone review it. Constraints *Are there specific things you can / can’t use? Something you have to make sure doesn’t break? Tools you have to use because of where you have to work in the codebase?* Making note of constraints can be super helpful. Maybe you have to use a specific UI library to complete this because the rest of the project uses it. Or perhaps this task has been attempted before, and you don’t want to repeat a version that didn’t work. Getting used to thinking about the constraints you’re working within can help prep your brain to think around these concepts. Architecture and Tradeoffs *Where does this code live? (login, ui, db, etc) What software quality attributes are we focused on for this task? List out the primary and secondary attributes (maybe a third if it feels necessary).* In this section, we’re focusing on developing our architecture and design skills in detail. Talk a little about how the codebase is structured, and where the work for this task will be located. Also, pick one or two software quality attributes that you think fit this task. Does the work you’re doing help improve the site’s overall accessibility? Does it make the application more reliable for end users? Does it help to keep our codebase’s maintainability within a reasonable level? Use one of the lists above or your own searches to build out a list of the attributes you might build for regularly, and pick out one or two of them that relate the most to this task. Then, talk a little about why you picked those traits and your thoughts about why they’re applicable. Being able to explain your reasoning here will both help you gain more understanding of the work you’re doing, and the words you’re using to describe it, and give whoever reads this document a better glimpse into the work you do and how you think about it! Initial Gameplan *Considering all the above, what seems like the path forward? What are the steps for how you think it can be solved/completed? Where are you starting?* Now that you’ve spent a little time thinking through the task, and some of the things you should remember about it (like how it’s structured, the tools you have to use, and what’s important to keep in mind while you’re solving it) - write out the steps you think you should take to accomplish the task. It’s perfectly okay to not fully follow this plan as you start to build! We can never fully predict everything that might happen as we start to work in a codebase. The goal here is to give yourself a solid place to start, with all the details we’ve listed fresh in your mind. Process Notes *As you solve this - keep this area updated with rough notes. What did you try that didn’t work? Why not? If you have to pivot, what did you switch to and why? Maybe something worked but you still pivoted - what tradeoffs were made, and what’s the reasoning behind it?* As the description implies, this space is all for you. Try to keep notes as you go. If you do have to change course from your game plan, why and what did you change? Did you find another problem you didn’t even know existed? Or maybe you were able to try a new concept out and it worked! Celebrate your process here. None of this needs to be in complete sentences or easy for anyone but you to understand. This space is all yours to help you keep thinking through the work as you’re doing it! Final Solution *You did it! Form a narrative. Now that you’ve got the issue solved, what does it look like? How did you do it? What did you learn along the way? Is the final solution the same as what you thought, or did the ask pivot along the way? Share screenshots if available.* The final wrap-up! Try to write this similarly to how you started with the big picture. Did your initial plan end up working, and if not why? Were there any interesting plot twists throughout the process? Share the wins, the struggles, and the end result here. Screenshots can be perfect here to see a visual of your work! I also typically leave a little space at the bottom to wrap up any lessons I learned for myself, and leave a little room to talk about my time estimate and reasonings behind how it turned out the way it did. But those are completely optional. --- Because I use a Notion database to help me keep track of these documents, I also have a few properties I can fill out related to the project this document is for, what my time estimate and result were, and the quality attributes I selected. Having those visible at a glance is super helpful for me. The biggest thing I’d recommend to track with this is the date you filled it out. Having that date to help you organize and find your documents is super helpful as your collection grows. I typically title mine based on the project it’s for and the name of the task, but you can name yours whatever you’d like! Now let’s talk about how to track our time for this task. The time estimate template This one is a lot less detailed, but just as important! Being able to improve your knowledge of how long different tasks take you will be a super handy skill as your career continues. The main idea with this template is to keep track of two sections: how long you think something will take you (the estimate), and how long it truly takes you. Our goal is to get those two sections to be as close to the same number as possible. Remember that our goal here is NOT perfection. That’s impossible to reach. Our goal is simply to get them to be close to each other. Most people (even managers) understand that an estimate is not a guarantee. But the closer you can get your estimates to the true time it takes you, the more reliable you seem and the more accurately your team can make progress. There are three main sections to this template. The actual numbers Most importantly, we want an estimated total time and an actual total time, as well as a calculation of the difference between those two numbers. Is our estimate higher, or is the actual total time higher? That difference is what we’re trying to keep as close to zero as possible. I like to break my time tracking down into categories, so I can also see if particular parts of my work take me longer (or shorter) than I think. For each of these, I do the same thing: make an estimate, and record the actual value. The categories I like to track are: Investigation: time to fill out my architecture design, do a little looking into the task, make sure I understand fully what I’m being asked to do, and that I have all the information I need to complete it. Coding: time to do the actual work. Most of my time calculation goes into this category. Testing: I use this for either writing actual unit or end-to-end tests, or for manual testing. This is where I double-check to make sure I didn’t break anything or track time spent on that one last piece of functionality that doesn’t quite work right. Review: any feedback I get on my Pull Requests or code reviews that require me to make changes go into this category. Space to record the numbers as I go The Pomodoro technique works really well for me with time tracking, though I change up my “working time” numbers to make them easier for me to calculate. I’ve found the most straight forward way for me to do this is to have a title for each section of time that I’m tracking, with space underneath each one. Then, I have a legend of colored dot emojis related to a different amount of time: 15 minutes, 30 minutes, and 60 minutes. Then, as I do my rounds of working time, each time I’m done with a round, I select the right colored dot for the amount of time I did, copy it, and paste it under the section the work I did belongs to. Keep repeating this until the work is complete! Once your task is done, all you need to do is count your dots, and record the total number they represent in your actual time section from above. Here’s a screenshot of what one of my completed sections look like, so you can better see what I mean. From this tracking section, I can quickly see that I spent 15 minutes on both testing and review, and an hour and 45 minutes on coding. If I don’t happen to spend any time on a section (in this instance, I’d done some investigating in a separate ticket, so I already knew the work that needed to be done), I just leave it blank. I have a section at the top of my page for tracking the total number for each category. So I use this area to keep track as I’m doing small rounds of work. Then, when I’m done, I add up each number and put it in the section at the top of the page for that category. Notes I also have a section for notes at the bottom of my document. I keep this area for anything relating to my time tracking. Did something break unexpectedly, causing my estimate to be off? Did I not need a section for some reason? Or did something work way better than I thought it would? Those are the kinds of things worth keeping notes of here. Can you tell why your estimate and actual times were off? Sometimes we simply don’t know, but being able to keep notes on the things we can realize as we’re doing them helps us get better the next time! Tying these together and talking about it with others You can use both of these templates together or on their own, and you’ll gain a great amount of knowledge about your skill level and your growth over time from them! But they can also really shine using them together. While these are great tools for your own personal knowledge and growth, I also highly recommend sharing them with someone else. It’s a great idea to set a goal to be better with estimating your time, and sharing that goal with your manager. Then, you can use the time estimation template to build up some estimates, and share those with your manager. Maybe you have a senior developer on your team that you really respect, and you’d like to get their opinion on the task you’re working on. If you’ve filled out the architecture design for that task, you can share it with them and have a conversation about it. They can potentially provide you with things to consider for your next task, or get you thinking more deeply about the quality attributes you selected, and why they may or may not have been the best fit for your work. The design documents are also great to share with your manager! It’s a great way to show that you’re starting to think about your work on a deeper level and starting to consider the quality and complexity of your work. It can also be helpful reference material for them when promotions and new work becomes available. They’re more likely to think you might be a good pick for the next big thing if you’re already showing them you’re starting to think about things at a higher level! The Notion template links The links for both of these documents as Notion templates are below. Please feel free to duplicate a copy for yourself if you like using Notion, or just take a peek at them to see the actual layout of them and adapt that for whatever tool works best for you. These documents are set up to be used within a Notion database. We won’t cover that in detail here, but the Notion documentation should be able to take care of those details for you (and we have a link to get you started below as well). In general, you can create a database within Notion, and then set a template to use for each new entry. That way, when you go to create a new item, it will automatically pull up these templates for you, so you don’t have to copy and paste them every time! And the fields at the top will be visible when you go to look at your database, which makes it a little nicer to get a quick overview of your documents and the progress you’re making. Now go forth and deepen your knowledge! - Time estimation template - Architecture design template - Notion database templates documentation...
Jan 6, 2023
14 mins
How to Avoid Common Pitfalls and Ace Your Take Home Assignment
During the interview process, you might be asked to complete a short take home assignment consisting of building out a small project with required tasks. But what is the best way to approach a take home assignment?...
Jul 20, 2022
6 mins
How to Write a Strong Resume That Will Be Read by Hiring Managers and Recruiters
Applying for software jobs can be stressful and time consuming. One of most stressful components is writing a resume. A lot of people struggle to write strong resumes and end up paying the price by getting passed over for tech interviews....
Jul 15, 2022
7 mins
How to Optimize Your Profile and Build a Developer Network on LinkedIn
LinkedIn is a platform designed for professionals to connect with recruiters and potential employers. If you invest the time to build a strong developer profile it can lead to potential job opportunities....
Jul 5, 2022
8 mins
What is Pair Programming and How Can It Help You Grow as a Developer
Pair programming is when two developers work together on the same section of code to solve problems and build better software. But why is the technique so popular and how can it help you grow as a developer?...
Jun 13, 2022
5 mins
How to Build and Grow Your Career Through Networking
What does it really mean to network, and does it actually work? How can you build out a network, and how does it help to grow your career?...
Apr 8, 2022
5 mins
Benefits of Software Apprenticeship & How to Make the Most of Yours
It’s no surprise that over the past year, many have started switching careers into tech. I was one of thousands of people that hopped on the “Learn to Code” train last year after losing my retail job. Being without a college degree, I looked into programming because it was one of the few industries where you could teach yourself the necessary skills without a long and expensive college education. As with many things though, the process of learning to code, and finding a job, proved more difficult than expected. About two months into a fruitless job search, a mentor of mine told me about This Dot and their Apprentice Program that had helped her get started as a self-taught software engineer. I was so excited to find an approachable entry point into tech for self-taught folks like myself! What is an apprenticeship? So what is an apprenticeship, and how does it differ from an internship? As I understand it, an apprenticeship is a program that provides hands-on work experience with the explicit goal of placing you in a job. An internship is more focused on general exposure to a work environment, or industry, without the explicit goal of hiring or placing you at the end. Another major difference is that most internships will require you to be an active college student pursuing a degree, while apprenticeships are generally more accommodating of unconventional backgrounds. Why do an apprenticeship? These are some of the key reasons I decided to pursue an apprenticeship at This Dot Labs. Keep in mind that every apprenticeship and every company is different, and the reasons I’ve listed here are specific to my experience in This Dot’s Apprentice Program. 1. Mentorship Opportunities Before I started my apprenticeship at This Dot, I was told I would be assigned a mentor that would meet with me once or twice a week. I didn’t realize that nearly all of my teammates and managers would also become my mentors. If I have a question, someone on the team is bound to have the answer, and everyone is more than willing to help. I’m only a few weeks into the apprentice program, but the meetings I’ve had with my mentor, teammates, and managers have already helped grow my skills immensely. 2. Room to Learn and Grow The whole purpose of an apprenticeship is to give someone the room to ask questions, fail, learn, and grow. In my first week as an apprentice, I was absolutely terrified of asking too many “stupid” questions. I struggled trying to do things on my own. Over and over, my managers reassured and encouraged me to keep asking more. They understand what it’s like starting out as a dev in your first job, and they are there to help you through every struggle. I quickly learned that if I ask questions early on instead of struggling for hours, I actually end up getting more work done, and being a bigger help to my team. They strongly encourage you to follow your interests and curiosities outside of software development at This Dot as well. I’ve already been given opportunities to try out other areas of interest in tech, such as Developer Relations (DevRel). In my first few weeks, I’ve been able to do things I’ve never tried before, like speaking on a podcast, writing blog posts (like this one!) and tweets, and moderating a panel at MagnoliaJS Conference. This room to experiment is a rare and valuable opportunity for an early-career developer. 3. Hands-on Experience Working on high-impact projects for major companies, and actually being responsible for the outcomes of these projects, is incredibly rewarding and validating. Being given a high level of autonomy, and the opportunity to “rise to the occasion” will grow your skills faster than any internship where you might be given tasks unrelated to your area of interest. The opportunity to build confidence, and validate your skills so early in your career, is invaluable. 4. The Team This point is obviously specific to my experience at This Dot, but it is so important to find a company that meshes well with your personality and values. This Dot greatly values good people, good work, personal growth, and a diverse team. I’m exposed to a lot of different people with different backgrounds and unique perspectives at work, which has been immensely valuable. This Dot even has a *Hire the Fempire* program that works with companies to hire more women in tech through their apprentice program. 5. An Accessible Option This is perhaps the most important point to me and the reason that apprenticeships are so invaluable: They offer an easier way to break into the tech industry for people that otherwise might not have the resources to be able to pursue a degree. They allow people with unconventional backgrounds to get real job experience, and change the trajectory of their lives. How can I make the most of my apprenticeship? You've done it! You've made it past the barrier and gotten your first tech job! Here are some ways I plan to make the absolute most of my time as an apprentice. 1. Ask Questions Now is the time to ask a lot of questions, and when I say "a lot", I mean *a lot*. If you are like the majority of people who experience impostor syndrome, this is something you will need to push past very early on. It will only hold you back. If, like me, you are terrified of sounding "stupid" or being found out as a fraud, try to reframe how you view asking questions. You are not asking a stupid question. You are simply trying to get unblocked, to allow yourself to do more awesome work. Don't stifle your own progress because you're afraid of appearing less knowledgeable than you are. If you're still worried about overloading your teammates or mentors with lots of questions, try batching your questions. Keep a list of questions you'd like to ask, and ask several at a time rather than spreading them out throughout the day or week. Lastly, be sure you know how to ask a good question, and always show gratitude to the person who's helping you. 2. Go Out of Your Way to Meet People In the first few weeks, I made sure to set up a short video meeting with all my managers, teammates- anyone I would be working with directly. These are the people that will celebrate wins with you, and help you when you're struggling. Once you get to know people long enough, you'll probably start to see that everyone has a "thing" they're particularly passionate about. You'll find out who to go to for React or Angular help, who to go to for GraphQL or Elixir knowledge. Fostering good, genuine relationships is incredibly important if you want to have a meaningful career (and life). 3. Don't Hide Your Struggles If you're struggling, don't be afraid to ask for help. If you followed my last tip for building relationships, hopefully you'll have found who you can go to for emotional support. Talking out your struggles can be one of the quickest ways to move past them, and your confidant may have their own personal experiences that can help you with yours. 4. Stay Open to Criticism Feedback is the fastest way to level up as a developer and human being. To use feedback most effectively, it's important to separate yourself from your work. If someone offers you feedback that is delivered in a not-so-nice way, you can still take something constructive from it, and use it to improve your work. In a lot of development work, it can actually be hard to know how or what to improve, so I try to view criticism as a blessing in disguise, and be grateful for being given some direction. 5. Set Goals and Track Your Progress Speaking of direction, it's important to have goals to work towards in many aspects of life. Set some short and long term goals for your apprenticeship, and share them with your mentors. If your mentors are good mentors, they'll support you in achieving these goals. Along with this, it's also important to have some way to track your progress. Some people like to journal, some people keep a Google doc or a Notion page. Personally, I've been sending myself a weekly email to track my progress. Point is: find a way to track your progress, and keep up with it regularly. Closing Thoughts I hope this post was helpful and inspiring to anyone trying to break into the tech industry! My hope for the future is that more companies will adopt apprentice programs, and structure them in a way that empowers early-career devs to ask questions, fail fast and fail forward, and be fearless learners. Tech still has a major diversity problem, and a lot of marginalized groups fall into the category of those with unconventional career backgrounds. If more companies offered apprenticeships, it would be a great step in the right direction for bringing more diversity into tech....
Jun 10, 2021
6 mins
My Career Roadmap
Every developer has their own unique roadmap. I love hearing these stories as they’re constant reminders that there is no right way. Anyone can become a successful developer as long as they have the passion for it. I’ll be sharing my roadmap in hopes that someone also realizes that there are multiple ways to be part of the programming world. My journey started when I attended a junior college in an effort to complete the prerequisites for a Biochemistry degree. I actually got far enough to start taking Organic Chemistry courses. However, my heart wasn’t in it. I found it boring and dreaded anything related to those science classes. I did find it cool that I could recognize some of the fancy ingredients in a shampoo. It just wasn’t what I connected with. I knew that something had to change. I was on track to transfer to a four year university in less than two years. I was always interested in computers and thought about programming. I still don’t know why I was drawn to that: maybe social media made it look cool? The dilemma was to either continue or take a risk by starting a whole new career. I didn’t want to spend more time at junior college, so I needed to make a hard decision: either continue with Biochemistry or drop it completely to pursue programming, but still transfer within the estimated year. I probably would have chosen to experiment with both at the same time if I had realized this a couple of years prior. However, I ended up changing majors within a week. It was one of the best decisions I have ever made. My first programming class felt a bit scary. The building was run down and cold. The room was cramped. There were only two females (including myself). The course wasn’t hard or discriminating against genders but it probably felt that way due to being completely new to the field and not knowing anyone. It didn’t discourage me from programming. In fact, I still remember typing up my first Hello World program. It was the feeling of writing code that made me realize that I was on the right track. Luckily, the junior college had opened up the new STEM building a year later. This really made the place more welcoming. It was actually pretty cool. There were outlets everywhere! A dream for programmers that we take for granted. One of the courses that I took was Internet Programming. This was a turning point for me. My professor recommended that I participate in the local hackathon that was coming up soon. He suggested forming a team with the two other females in class. I never once thought he was discriminating. I honestly believe that he saw potential in all of us but we were lacking confidence in a male-dominated world. We participated in the hackathon as a female group. It was my first time working with a team and presenting our project to the public. We didn’t win any awards, but it provided some of the confidence that I was lacking. I finally understood that it didn’t matter what gender you are. I found a love of programming and wanted to be one of the best. I ended up getting recruited for a local internship through the hackathon. I was able to learn about realistic expectations when building a project for a client. The lead developer was also very open to teaching a complete newbie. This is where I learned the basics for web development. It was this type of support that helped shape my career. I graduated from junior college with an associates degree in Chemistry and transferred the next semester. The one regret that I do have in my career is the university that I chose. It didn’t have the best resources for the Computer Science students. The classes were boring and most of the professors didn't seem to care. If you weren’t on the game research cohort, you were just another student passing through. During this time, I got a chance to be part of a research team. However, I decided to accept an internship instead. It was another difficult decision as both had great opportunities. I still think that the internship was the best route as it helped me later on. The internship only lasted for the summer. I learned Polymer during this time. The project was my first deployment and it was used by the city. It was also another great confidence booster. I returned to school with the goal to find my first job before graduation. Truthfully, it was very discouraging, even with my internship experiences. Most companies wanted developers with years in programming. They really don’t make it easy for junior developers. I’m almost positive that I placed over 100 applications. When I did get a response, it was a decline. I also attended the career fair that the university organized. That’s where I found the company that gave me a job offer. I started working for them after graduation. This led to web development in the Drupal world for a little over 2 years. It was a small company but provided development growth. I learned the importance of quality assurance and time management. I also acquired the skill to advocate for higher priority tickets. The most important lesson was that a project can only thrive with a unified team and proper documentation. However, the company had a tremendous downsize due to the pandemic. I was once again on the job hunt. Fortunately, the connections I made during the summer internship helped me find a job at This Dot. There was still an interview process, which I passed due to all the career choices that were made. I’m very excited to be here. I’m working with LitElement projects and more structured work environments. It really is a big difference from a very small company. I’m now pursuing the path of being a mentor, a dream that I had since my first internship. I’m working on improving a mentorship program and making sure my mentee has all the support she needs. I barely have a bit over 3 years of work experience. The time went by very quickly and I’m still excited to be programming. I can’t wait to see where my roadmap will be in the next upcoming years. Tweet me your favorite moment in your roadmap!...
Feb 2, 2021
4 mins
Computer Science Degrees are Optional
College is not for everyone. Don’t let the pressure stop you from doing what you want to do with your career. Success as a programmer can be accomplished regardless of a degree. There are pros and cons with any path....
Jan 5, 2021
5 mins