#like for me managing the backend and communication stuff is usually a full hour of work

[bitchfitch]

Do y'all ever see a post that just like. Haunts you forever? And which consistently comes back up when you're trying to get to sleep

Anyways, if you do comms the whole "2+ characters in a single piece costs less than if they were bought as separate commissions" thing Isn't supposed to be a buy one get one x% off type situation.

Your commission prices should be accounting for the time you spend communicating with the client, the time you spend on file storage and prep, and the time it takes to properly document your communications and the transaction. Those things all take time and it Really adds up when you do enough comms. And the time they take? doesn't usually change much based on the number of characters.

That's why the second, third, etc, character can cost less. Not because you're giving a discount. Right. Right? Y'all aren't cutting yourself a bad deal, right? You're Not paying yourself less than an exploitative boss would pay you for that time and skilled labor, right?

[fullstackhustle]

How to Ship Side Projects

Working on side projects helps me learn new technologies, improve as an engineer and designer, and exercise my creativity. Through building side projects (which range from the mildly useful to the completely inane), I’ve learned that momentum is paramount to getting things across the finish line(too often my GitHub repos become ghost towns because I can’t decide what technology to move forward with or visualize the final user flow). Here are some valuable solo project management skills that have helped me stay focused to maintain momentum throughout.

Ask Why?

First and foremost, ask yourself why? What is your motivation behind working on side projects? Is it to learn new technologies and frameworks? To make something people want to use? Or just to troll your friend, Jake?

Your objective shapes your approach to working on side projects. For example, if you want to learn new technologies, then maybe you shouldn’t optimize onshipping a complete product. Conversely, if you want to make something people use, then just choose the stack you’re most productive in.

For me, it’s to troll Jake, so I stick to my stack of Koa and heavy, heavy jQuery(kidding, though not really).

Write it Down!

Everyone gets struck by inspiration at various times during the day. Get in the habit of writing down every random potential idea (sometimes not even a full idea, but an exploration: write down a sentence that’ll inspire you to think of the full idea). Make sure the path from thinking of the idea to memorializing it in an easily accessible way is as frictionless as possible.

Some people like to email themselves or chat Slackbot on Slack.

I use nvALT (it’s a free, plain-text mac app that I can summon with a hotkey and jumps right into a blank note) with a Simple Note backend (also free; they have an iPhone app so I can use it on the go). I have this giant note of just “ideas” (also a separate note of “blog ideas”):

This means that next time you have an empty morning or evening, you can review your ideas. Then, you can start planning the ones you like the most or are particularly inspired by.

Wear One Hat at a Time

One danger about side projects is wanting to jump into all aspects at once. You start creating wireframes, writing your server routing logic, and thinking about use cases. Stop! The amount of micro context switching and decision making will lead to mental and emotional fatigue, ultimately slowing you down.

Instead, do one thing at a time. This means wearing your Product Manager hat first and answering these questions:

what is the objective / end goal?

what are the main use cases? (ideally, you should start with only one use case)

what tools are available out there for me to use to build this?

who are my target users and how do I reach them on the inter webs?

what should I name this thing?!*

*For me, choosing a clever and hilarious name often motivates me to finish something in 1/10th the normal time. As such, I like to dwell on the name for a day or two. If I can’t find something great, I just go with a vague project name with the hopes that later I’ll uncover something awesome.

Other Product Management tasks include:

thinking about the ideal user flow

creating a loose mock up of what it should look like, etc.

researching the APIs, documentation, etc. and preparing that info so that when you begin development, the resources are readily available

loosely plan when you’ll wear your Engineer and Designer hats

Since I have a full time job, it’s easy to overlook these important steps when I come home in the evening. To keep myself on task, I like to add Google Calendar events with their descriptions as small, self-contained tasks to complete:

By writing it down in a calendar event, I can free up some of my mind to do other stuff, knowing that I can jump right into the tasks listed later when the time arrives.

Bonus Tip: Cut Scope Aggressively

Since I like to optimize for shipping, it’s important to me to cut scope aggressively. This philosophy usually guides me to first write a library or CLI, from which I can make a web service with a front-end UI (though many things I make end up just being a CLI).

The cognitive overhead of thinking about how the final product should work, especially thinking about the pros and cons of the hundreds of ways an end user can interact with your finished project, can often destroy momentum and halt productivity on your project. It’s important to think about your project in smaller pieces: how will Engineer you want to interact with your library? How will App Developer you want to interact with your API?

This approach means you’re breaking problems into smaller and simpler pieces, which are often more manageable than tackling everything at once.

Empathize With Your Users

How your user (whether that is yourself or a specific audience you have in mind) uses your project should determine how it is structured. There is a ton of literature out there that defines the design exercise of coming up with story boards, etc. so I won’t enumerate them here.

The key thing to remember is that these user flows can guide ways to manipulate necessary data so that your users to accomplish their jobs.

Working on a library? What are the minimum arguments necessary, with the fewest calls, for your user to do her job?

How about an API? What job is your developer accomplishing with your API? How does that determine what routes to provide and what parameters to expose?

A web or mobile app? How does the UI need to communicate enough so that your user can easily navigate it without confusion or frustration?

In terms of actual design for a web app, I typically have a loose idea of how the final product will look at this stage. But I don’t write any CSS or `margin: 0 auto;` until the very end. Plus I rely heavily on Twitter’s Bootstrap, since I’m familiar and quick with it.

By this time, I would break apart engineering tasks to discrete TODO’s, then write those down (usually in a GitHub issue). This way, when I start developing, I don’t have to revisit these decisions, which could impede my momentum.

Write First, Refactor Later

If you’ve ever had to write an essay or blog post, you know sometimes it’s not easy. Something I’ve learned about writing that has helped me is to not write and edit at the same time.

The act of writing (creating content) and editing (refining and removing content) uses two parts of your brain. Doing both at the same time can be counter-productive: three hours and two cups of coffee later, you’re still word smithing the same sentence.

Same goes with writing code. If you’re goal is to ship, then who cares (right now, at least) that you’re copying code and not being DRY. Put that tenth callback in that single 400 line index.js file, get it to work, then refactor that later when you have your “Editing” hat on.

If you’re interested in continuing to improve and/or maintain your code, then, for future you’s sake, revisit it later, clean it up, and make it human readable.

Bonus: Learn About Your Users

If you do plan to put your side project in front of other people, then it helps to add some cursory tracking for analysis later. My go-to is Segment with Google Analytics enabled (both free!).

This allows you to measure traffic and usage on your app, as well as find out where traffic is coming from (if it’s a web app). You can also setup key conversion events to measure your funnel, see where people are dropping off, etc., so you can improve your product.

If you want to be more thorough with your analytics and have the intent to grow your side project, here is a great article on using a $9/month marketing stack.

Disclaimer: I work for Segment.

Ship it!

This is the most difficult part of the side project development lifecycle, when you’ve built it to 90%, it works mostly and looks half-decent. Again, this ultimately depends on your goal: if you just want to make something your friends can use, show it to them for feedback; or if you’re trying to get it listed on Product Hunt, then take the extra week to polish the design, write tests, ensure analytics are in place.

Typically, I have a user in mind when I build something. I would find out where those users like to hang out on the Internet (what tools they normally use, what forums they browse, which subreddits they read, what Slack channels they’re in, what newsletters/blog they read) and share the finished product there. If I were serious about customer development, I would try to get as much feedback as possible.

The main takeaway is to consider your motivations and then optimize for them. If you’re optimizing for shipping, then being intentional about planning, researching, designing, and building will help maintain focus and, more importantly, momentum, that can help get the finished product out the door and in front of your users.

Originally published at blog.andyjiang.com.

[our-beginnings]

Michael Chase, Senior Software Engineer at Ancestry

Tell us a bit about who you are, and what you do now.

My name is Michael Chase, and I’m currently a Senior Software Engineer at Ancestry. I serve as a full stack engineer (across both front and back end) and architect for my team at Ancestry. I’m also an active member of DevColor, a contributor to the Sequel app project, and a crypto-currency trader.

What do you get up to day-to-day at Ancestry? What’s one of your favourite things about working there?

My day-to-day at Ancestry usually starts off with me making my famed breakfast of plain oatmeal with a cut-up apple and cinnamon. I catch up on emails and Slack, and try to write any last minute code (usually Javascript or Node) before the daily standup. After that, we might have a technical discussion or some other meetings, and I then spend an hour or two working before lunch. Currently, we’re working on a survey project to collect phenotypic data (that is, observable characteristics/traits). After lunch, more meetings and writing code.

One of my favourite things about Ancestry is the people. I consider myself very lucky to be on such a great team with talented engineers and a great manager.

Is this where you expected to find yourself when you were a kid in Maryland? If not, where did you think you’d be?

I have memories of being a kid and wanting to work on spaceships: rockets specifically. I thought I would major in “aerospace engineering.” At some point I also thought it would be cool to be a tradesman doing plumbing, electrical, and carpentry type of work.

I took to computers at an early age. In the late 90s and very early 2000s, me and my brother were always tied to my grandmother’s computer. However, I had no idea I would (or could really) work with computers until my high school guidance counselor recommended I take a vocational IT class. There, we learned PC basics, including how to take them apart. That made me think I wanted to work on hardware in some way, and in the years leading up to graduation, I thought I would most likely be a computer repairman.

back then I thought I would hate sitting and staring at a computer all day, “typing.”

After deciding to go to college, that transitioned to this idea of making microchips and circuits (we had learned basic wiring and circuitry in the class). When I did get to college, I took up the “engineering” track of the Computer Science program, and it was that which led me to software development. Ironically, back then I thought I would hate sitting and staring at a computer all day, “typing.” But now, I absolutely love it.

What were the ‘eureka’ moment (or moments) that sparked your journey?

My journey to being a developer started a bit later than some. The first time I ever wrote code was in college!

In all honesty, life just kind of fell together in a lot of ways. In high school when I wanted to be a “tradesman” and didn’t want to go to college, I had a teacher named Ms. Nolan that would tell me (and the rest of the class) “you’re not dreaming big enough” and “you’re going to college and you’re going for free.” I thought she was absolutely crazy.

One day, my guidance counselor told me there was a free spot on a college tour, so I went. The colleges I visited were the only ones I applied to. This is also where I got introduced to my scholarship program - DNIMAS. That was a eureka moment of sorts: Norfolk State University didn’t have a Computer Engineering degree, which was what I’d originally hoped to do. But I wasn’t about to pass up a full ride, so I enrolled as a Computer Science major on the engineering track.

As luck would have it, I thoroughly enjoyed coding and was exceedingly good at it. I remember one day during my first semester: we had just started to really learn to code, and I went back to my dorm room after classes and just began playing with C++ using Dev C++. The more I understood what my code was doing, the more I wanted to write and learn. I was hooked!

This passion got me into some pretty good internships at the Department of Commerce, JP Morgan Chase and IBM. In the end, I took a job from IBM, but I was assigned the most boring role one could ever do: Sharepoint Administration.

The more I understood what my code was doing, the more I wanted to write and learn.

My biggest eureka moment occurred while I was at IBM, when a Google recruiter reached out to me on LinkedIn and I ended up interviewing there.

It was a total culture shock. The type of things I needed to know for college, DoC, JP, and IBM were worlds away from Silicon Valley. I would compare it to working as a car salesman, then one day stumbling into the car factory assembly line and being expected to know exactly how to put the cars together from scratch. I didn’t get that job at Google, but I learned that there was this whole other side of technology out there and I had to be a part of it.

From that moment, what path did your career take? 

I went from thinking “Oh, I have a decent job. If I stay here 5 years, I’ll get promoted” at IBM to thinking, “I need to learn how to be a true coder, how to solve the world’s problems and make the sharepoints, not manage them.”

The first step was to find a job in the Bay area. I applied to a lot of places and didn’t really get much. I ended up falling back to plan Z: switching from IBM to Accenture. It was hilarious, because one of my interviewers even said, “so this is just a business card change for you.” But I moved to the Bay Area with my then girlfriend (now fiancée) and joined Accenture’s SF office, then set out to find a real coding job.

“I need to learn how to be a true coder, how to solve the world’s problems and make the sharepoints, not manage them.”

It was a huge leap of faith. I wasn’t very skilled at the time so I was relatively underpaid, supporting both of us while my fiancée got her Masters degree in Counseling Psychology. Accenture had a wide reach of clients it served and projects one could be placed on and as luck would have it, my Sharepoint hacks done in HTML/CSS/Javascript positioned me to get me contracted on an Apple project (which I actually had to fight for, but that’s another story). Working there as an Accenture contractor isn’t quite the same as working there as an employee, but I still learned a ton. That knowledge allowed me to get into a startup called Yo, which is where I picked up almost all of my backend experience. When that ride ended, I came to Ancestry.

Was there a person, course, or other resource that really helped you along the way? Was your family supportive?

Practice was really my best friend. A lot of what I learned, I taught myself— by trying things and practicing. I have always been curious about how things work. As a small child I would take apart my toys (although they rarely got put back together). Everyone around me was very supportive; most of my teachers (both in high school and in college) saw the potential in me and would do what they could to push me to be as good as I could be.

My family was supportive as well. It was a win-win for them: as I got better and older I became the family tech support guy! All that being said, my biggest resource was probably my scholarship program. I can’t imagine my mom would have been able to afford to send me to college on her own. So without DNIMAS there is a good chance I would have ended up going to community college. I’m sure I still would have made it, but it’s hard to say how much more time it would have taken me.

It was a win-win for [my family]: as I got better and older I became the family tech support guy!

There seems to be a certain pressure on underrepresented folks in this industry to change it from within (while not always being empowered to do so). How do you deal with this?

I feel this pressure as well. I started out by doing things like speaking at my church, going back to NSU and my high school to talk, and tutoring and offering advice to peers and students. I think what I do best (for better or worst) is speaking up about things very loudly. As my fiancé would word it, I “speak [my] truth even if [my] voice shakes.”[1] At work, I’m very outspoken. I’ve developed the type of reputation where people ask me for my opinion when I’m quiet, both because they value it and because it’s unusual for me to not have one.

The hardest part, though, is being consistent and resilient. There are days when I absolutely am ready to quit my job because of the needed change and lack of diversity. However, I always tell myself that if I leave, who will be there to make this change? So I press on and I go to therapy!

[1]Maggie Kuhn

If you could do everything all over again, do you think your journey would be the same? Would you want it to be?

If I could do it all over again, I would probably study harder and try and get directly into a “big name” place like Google. When I first graduated, somehow I just had no idea this world existed, so I would try and do more to get to where I am now faster.

There is, though, a decent chance my journey would have been the same. Because of how life works, I wouldn’t actually want it to be different because of the ripple effects. But speaking in isolation, I definitely wish I could have gotten up to speed faster and thus progressed in my knowledge even more.

Is there anything about the internet or technology that you remember from your childhood/early years that makes you feel nostalgic?

Napster comes to mind. Me, my brother, and another friend of mine use to be really into downloading “stuff.” We didn’t have internet ourselves so we had to perfectly position our computer by the window to “borrow” the neighbor's wifi. Those were the days.

How do you see your next five to ten years? What are you most excited about? Perhaps most afraid of?

In five to ten years, I hope that I’ll look back and think, “man what was I thinking.” I’m all about exponential growth. I flip perspectives very quickly and the goals I have today will likely not be the same in a year.

That being said, ideally I’ll be working on a cause, and less about making money. One of the things I’ve truly come to dislike is capitalism. Most of us work and make money for the sake of survival. I believe that it’s rare to find someone who works where they do solely because of the pure joy they get out of it. Don’t get me wrong, I love writing code, and I do fun stuff at Ancestry— but if I won the lottery, I’d quit that day. But wouldn’t everybody?

The thing that excites me the most right now is crypto-currency and the overall prospect of being able to run my own business - or at least be my own boss. Whether that’s being the CTO of Ancestry, CTO at Sequel, running a Cryptocurrency trading related business, or just having a bot that trades for me while I sit on the beach— I’m not sure.

Thanks so much to Michael for his time and excellent responses! You can find him on LinkedIn. 

Also thanks to /dev/color and their speaker form, which has connected me to both Michael and Nick!

[1]Maggie Kuhn