DEV Community: Andy Johnson

The Dollhouse and The Dresser: A Lesson in Project Management

Andy Johnson — Sun, 09 Feb 2020 06:13:44 +0000

The Dresser

After moving to our new house, my kids no longer were sharing a room, and thus needed dressers of their own. Instead of buying a flat pack Swedish hex bolt puzzle, I decided that I'd dust off my woodworking skills and make them myself. I had a few tools and the space in the garage. I figured with a router, a Skil saw and a straight edge I could build the whole thing.

At the time, I was being a bit naive. Back then I hadn't done much woodworking since high school and I lacked the experience to properly estimate what would be needed to build a dresser. Undaunted I went to the hardware store, bought the needed sheets of veneered plywood and hardwood and begun work. I had my Skil saw, my straight edge and my router. First step was to rip down the plywood into the correct widths. I clamped down a straight edge and tried my hand at long Skil saw cuts. The board sagged on the saw horses and bound up the blade. Attempted it again - same results. I flipped around the setup to cut from the other direction and finished the cut. It looked like it had been cut with a cheese grater. I set aside everything and faced the reality that I needed more tools.

These tools weren't in the original budget. Thus, every pay period I'd buy a few items, slowly accumulating a proper shop. My Dad donated an old table saw to the cause. I studied, researched, binged YouTube woodworking channels. As a researched I kept building. Night by night, weekend by weekend, the dressers started to take shape. I learned ways to improve my process cheaply and effectively; for example, sheet goods need support when cutting them so they don't bind, so I put a sheet of foam insulation under the work as I cut it. I salvaged my original cut that would have been waste. The deliverable was delivered, albeit far past the original estimate.

I delivered on the project, but way over budget and past time. I learned about proper estimation and I learned more about building cabinets. I know now that with this experience I could build anything with a Skil saw, a router and a straight edge. I know this because I've built other projects with minimal tools.

The Dollhouse

I had kicked around this idea in my mind for about 5 years. A crystal clear picture of a brownstone loft Barbie house for one of my daughters. Complete with elevator, Brooklyn style brownstone facade, perhaps even a party patio. I had been planning this idea in my mind for years, but none of my daughters wanted a doll house during that time. A week before my youngest daughter's birthday, she asked me if I could build her a dollhouse. A week. Before her birthday. She wanted a dollhouse.

I could have gotten online, paid 2 day shipping and gotten a press board behemoth that would suitably resemble a doll house. But an engineer has to engineer, right?

I drew up a basic sketch at lunch on Monday. My wife and I drove to the hardware store that night. I sat on a lumber cart for an hour in the store sketching the final dimensions and doing the cut lists in my head.

We brought the materials home and loaded them into the garage. I began work the next day. Every night I'd come home, head to the shop and start work, break for dinner, and then work until I felt I'd be annoying my neighbors with power tools. I delivered a doll house carcass with no styling details the day of her birthday. It was the only deadline I've ever missed. (The dresser never had a firm deadline.) However, she was thrilled. She played with the doll house for a week and I took it back to the shop to be finished.

It features a two story Brownstone loft, with working elevator, party patio and swing out Barbie Bodega shop.

Conclusion

I've built a lot of software projects over the last half decade of being a developer, and I've never failed to deliver on any single one of them. To me, it's a point of honor and loyalty, and I don't intend to fail on a deadline. The managers I've had in my career have partnered with me to ensure my success, so I'll do everything I can to ensure that success. However, if there are constant tight deadlines, improper prioritization and daily escalation, you're going to get burned out. Make sure to take care of yourself. Take breaks and time off to recharge. Set reasonable deadlines and update expectations all the way from the customer to sales and project managers.

The Dresser analogy teaches that if you don't understand how to solve the problem, then you better do more research before you estimate the work. Because the alternative is blowing out scope, time and abandoning the project.

The Dollhouse analogy teaches that even the most seasoned builder can have a deadline foisted upon them. Knowing your strengths can help assess the work to be done and better communicate an estimate. However, sometimes the situation is escalated, the project is due and you just have to push as hard as you can to deliver on the deadline. And if you're not sure how to estimate the work because it's all new to you, then get help from a more seasoned veteran that's done similar work.

Neither of these situations are ideal. Prioritizing the work is key to ensure longevity of the long term project. If everything is important - then nothing is important. Managing expectations of all stakeholders and setting reasonable deadlines is key to a successful project.

Why I Mentor

Andy Johnson — Sun, 10 Mar 2019 04:58:38 +0000

In 2007 I graduated with a Geography degree. It's a reasonably narrow field - and not having many in-state prospects I took the first and only job offer. It was a small family owned firm that sold GPS and surveying equipment. A technical support gig for GPS and surveying equipment. As a new graduate with only a single child, living in an apartment and low expenses it was a good fit. But it didn't stay that way. Life changes, but the one thing that held constant was my pay - for 7 years. By year 4 I was looking at opportunities - but lacking other experience, and a crashed economy had flattened hopes of getting somewhere better.

But at the end of every day, coming home to my growing family, making enough to scrape by began to wear on me. Around year 5 I decided I would approach my boss about a raise to my pay. That didn't go over well. I couldn't find any new opportunities with my experience. I couldn't get a raise. I was trapped. I went back to school online.

I found a college with a competency-based learning model. Basically, if you already know stuff, you take a pre-assessment and if you do well, study for a week or two then take the final. The tuition was a fixed amount per term too, so you take a full-time load (for Fed student aid reasons) and if you finish early in your 6 month term - you register for a new class, and then a new one when you finish that. I think my record was 21 credit hours in one 6 month term. So just like Ben Folds said, it was only 15 grand. Took me 2 1/2 years.

https://www.youtube.com/watch?v=Yr_s6-Q7f00

It was super hard.

1 year prior to graduating with a degree in software from the online college, I applied at a hot tech startup in my area. I knew I couldn't start out there as a developer, but I could work technical support and move up. I announced this ambition in my interview to the recruiter, hiring manager - everyone was on board.

https://thepracticaldev.s3.amazonaws.com/i/o2s1dq6ozyw3cssnpd64.png

And they offered me a job. So I just hustled. Because like Harry Potter, I really wanted to be a Gryphindor, and I wouldn't settle for any other house. I wanted to be the best, so I did my best. By the 3rd week my boss pulled me aside and asked me to be one of the Tier 2 technical leads.

I had no idea they were watching me for this, I just went to work every day and worked hard. Like the Dread Pirate Roberts, I learned whatever anyone would be willing to teach me. I was driven and hungry.

https://thepracticaldev.s3.amazonaws.com/i/nab22j3jvg6fisfcmoul.jpg

I served as the Tier 2 technical lead over my cohort in support for a year. New hires came onboard as the department ramped up. 2 fantastic peers joined me on the Tier 2 team and they were superior to me in so many ways. I learned so much from them.

During this time I began courting my future boss in product development. I went to his standup every day to report escalations from the support department. During this time I forged a partnership and friendship with him that is still strong today. In time I finished my degree and talked to him about bringing me over to his team.

He provided a mentor to test my development skills. I was given real work. My mentor sacrificed her lunch time to help me out. So I coded a storm at night and brought questions for her at lunch. (She's super rad, and recently now she's my technical lead!)

He told me that my move to development would be a one-way move. Meaning if it wasn't a good fit, there wouldn't be a way back.

I was terrified but confident in my ability to make it on the team. I knew the company already had taken a chance on me to hire me in technical support, and I'd proven myself there. I could do this.

After getting my feet under me on the job for almost a year, I was approached by my boss to provide some mentoring for an employee in support. He wanted to become a developer and my boss wanted me to help answer any questions and guide him through the process of development.

As it turned out, there were more. Others in support that wanted to become developers and came from varying backgrounds - some college, or a finished degree but not enough experience, some currently in college.

This is when I launched Project Space Kittens. Because when you need a cool name, you look at your mousepad, and yep. That's a cool name.

https://thepracticaldev.s3.amazonaws.com/i/5wcoh4265mysfxynv9yr.jpg

It's a cat, riding bacon, in space. Literally Reaching for the Stars!

The Space Kittens meet up weekly during lunch and discuss personal wins, show & tell cool dev projects we've done and work through problems. I try my best to make it a meritocracy - basically you can take more time if you do your due diligence on your time out of the group. But if you're there to ask arbitrary questions and haven't Googled them, you won't get time unless nobody else has anything to get help on.

I've been doing Project Space Kittens for over 2 years now. And last month something big happened. One of the members of the Space Kittens was offered a position in development on my team. And the irony is, that I was reassigned to a new technical lead on the same team, and he took my place.

https://thepracticaldev.s3.amazonaws.com/i/savuvl1nu5qsyuyelojx.png

The greatest gift that a mentor can receive is a protege qualified to take their place.

It was such a humbling and amazing experience to see this all go full circle. Looking back at my own progression to become a mentor, and now for one of my proteges to become a mentor - I can't express my gratitude for everyone that's helped me on the way. And to see the growth of the Space Kittens over time. It's so awesome to be part of it all and help everyone do their best.

So this is why I mentor, because I know the struggle of making it to the top of the success mountain. And as long as I'm alive on this little blue rock in space, I'll help as many people up to the summit as I can.

Indiana Jones Refactoring

Andy Johnson — Wed, 01 Aug 2018 19:05:49 +0000

I remember as a kid the first time I watched Indiana Jones and the Temple of Doom. Exciting, adventurous, and terrifying at times. When I became a developer a few years ago, I felt the same way. In the films, Indiana is after a specific artifact, preventing bad guys and gals from destroying the world. He travels far and bushwacks through the jungle with his trusty bullwhip to defend himself and get out of danger.

As a new developer, unlike Indiana Jones, I didn't always keep my eyes on the prize. Often I was too timid to refactor methods and functions down to their basic needs. And I assumed the developers before me that took on dependencies were wise and using massive libraries for small benefit was the best choice.

I remember a specific project when I was connecting to a third party API, using their provided Java library. I only needed the authentication method to call their API. My code could handle the HTTP calls, error handling, retry logic, paging, throttling and all the rest. In my case, their method of API authentication was my Ark of the Covenant, or Mystical Stone, or Crystal Skull, for the younger crowd. In other words, I didn't need the jungle, the temple, the jeep, the local to lead me to the temple or anything else. I just needed one core piece. Yet, my code was using that core artifact, and also took on the temple, the jeep, the jungle and so on.

On a bold day I decided that I was tired of maintaining a whole library for one piece, and hacking around that dependency. I decided to grab a machete and bullwhip, and I would bushwack deep into the jungle of that library and extract the artifact I needed. When I stepped in to that breakpoint in my IDE, I knew there was no going back. And after some time finding the authentication classes, I extracted the logic to authenticate the API. It turned out to be one method, that I copied and pasted into my code.

I removed the dependent library and dropped a huge amount of weight on the server hosting it. I learned how to step out of my comfort zone, and gained confidence and felt powerful. I had ripped the heart out of the library, much like in that scary scene in Temple of Doom.

Dependencies aren't bad either. If you use a library for the core of your workflow, using someone else's maintained, secure library is a great way to save time and money. But if you only need one aspect of the library, don't be afraid to dive into their code and see how they did it, so you can do it better. You just have to accept that you're on the hook to update it when they update their API.

How to learn tech skills outside of your wheelhouse?

Andy Johnson — Tue, 05 Dec 2017 21:35:51 +0000

I'm a backend engineer that does a ton with API's all day, but my front end kung-fu needs time in the dojo. What things do y'all do to learn technologies outside your daily wheelhouse?