Skip to content

Instantly share code, notes, and snippets.

@jcasimir

jcasimir/Make Good Projects Great.md

Created November 28, 2023 00:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save jcasimir/c6b63382595dd40e959be5f24efb37e1 to your computer and use it in GitHub Desktop.
Save jcasimir/c6b63382595dd40e959be5f24efb37e1 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Make Good Projects Great.md

How to Make a Good Project Great

Opening

  • Building projects is the best way to develop and refine your skill as a developer
  • And while you have 0 years of professional software development experience, people are going to be skeptical that you can actually do the things you say you can do.
  • Your portfolio serves as a form of proof. Your portfolio isn’t going to win you a job, but it can win you an interview.
  • And one thing I’ve been saying over and over the last few months — job applications do not reliably convert to interviews, but interviews reliably convert to jobs.
  • Typically if you get into about 5 interview processes then you’re going to get a job offer. 10 interview processes and you might see 2 or 3 job offers.
  • So you build projects to build your skill, but you might as well build projects that build your portfolio that could then make someone say “sounds interesting…bring them in for an interview.”
  • What you don’t want is a portfolio that seems basic because the projects are just simple CRUD applications.
  • If all you’re doing is essentially allowing the user to type things, saving it, then displaying it on a different page, then you’re wasting your time. It just looks like a tutorial app.

Some Things That Don’t Work

  • Along your Turing journey there are some projects that we assign, some you have input on, and some you plan yourself.
  • Over the years people have built some really neat projects that…didn’t help them get interviews.
  • If the only way you can be engaged in a project is to do something where the purpose of the app is interesting to you, then that’s what you have to do.
  • By my first suggestion is to not bother building things that sound meaningful UNLESS they are directly tied to an employer or industry you’re targeting.
  • Unfortunately, feel-good stories don’t convert into interviews. You can try to pluck the heartstrings through a demo comp, but it’s not going to get you a job.
  • Fun apps that your buddies would want to use don’t convert into interviews. Please don’t bother making yet another craft brewery application.
  • At least in this market, you’re not going to win interviews by showing how interesting YOU are. You’re going to win them by showing how interested you are in THEM.
  • That means building applications that look and sound like the applications that an employer builds. You want to involve some of the same technologies, same challenges, and show that you’re willing and able to tackle them.
  • If I were in your shoes, I’d be building projects that are interesting because of the technical achievement and boring in their purpose.

Iteration

  • The first place where I think you can stand out is in emphasizing iteration.
  • Most projects are built and explained as just a finished project
  • What’s most interesting about you as a software developer is your PROCESS, not your knowledge.
  • A finished product doesn’t really show off a lot about your processes.
  • What would it look like to build a project in really clear and clean iterations, where you could show off each iteration on it’s own?
  • For a simple example, imagine you’re building an e-commerce application.
  • You build out a couple iterations that allow someone to add items to their cart and check out.
  • But then really hone in on order confirmation.
  • In the first iteration, just have the web page say “Your Order is Confirmed”
  • Then in the second iteration, send them a confirmation email in the request/response cycle (which is slow)
  • Then in the third iteration send the email using a background worker and a job queue
  • Then in the fourth iteration send a text message along with the email
  • Then in the fifth iteration allow the user to set a preference for notifications over email, text, or both.
  • Then in iteration six send automated updates when the order is marked as shipped
  • Then in iteration seven invite the user to submit a review once the order is delivered
  • It doesn’t really matter what features you’re building here, you’re trying to show off the process. Here’s how I built something that delivers value to the user, then I made it better, better, better.

External APIs

  • Any application you work on in your job is going to involve coordinating several other applications.
  • Maybe it’s a full “microservices” architecture, maybe it’s just fetching and posting data to some APIs
  • But standalone applications are pretty rare these days.
  • How are you coordinating multiple data sources in your applications?
  • Let’s consider the case of an external API you don’t control.
  • Just consuming data and displaying it to the user isn’t really that interesting.
  • Some ways you make it better:
    • How does your application still work when the external API is down?
    • How do you deal with possible rate limiting on their API?
    • How do you run tests locally without hitting the external API?
    • What would it take to change API providers if your main service were to shut down?
    • Can you implement caching so as to reduce external requests?
    • What if the external data changes without your user refreshing the page. Could you dynamically update the content?
    • What if your number of active users increases 10x or 100x? How would that affect your API usage?
    • What if the external API is just a bit slow? How do you avoid slowing down your own application’s pageload?

Performance

  • The third area I want to emphasize is performance.
  • It’s cool when you can make an application that works at all.
  • But if you want it to look like a production application, you’ve got to put time and energy into performance.
  • One of the first ways to do that is to look for opportunities to generate data.
  • When you’re trying to show off that an application is well thought-through, it’s smart to generate a lot of data.
  • If it were an e-commerce situation, generate at least a hundred products, a couple thousand users, and ten thousand orders. How does your application hold up?
  • What work can you put in to make your application fast? Or what can you do to make it slow, then work to make it fast?
  • For instance, you’ve seen on Amazon how it’ll recommend other products for you. Customers who bought this also bought that.
  • If you’ve generated a hundred thousand orders then you can do the calculations to see what items crossed over most commonly and implement that in the page.
  • Then as you get it implemented you’ll see that your page response time is slowing down. How do you prove it?
    • Pick some sampling of your products
    • Run a benchmark to load their product page a thousand times each WITHOUT the suggestion box of other products
    • Now put the suggestion box back in and run the benchmark again
    • Now you can prove just how slow it is
    • Now you work to make it faster
      • From a front-end perspective, you could pull that suggestion data in as an API call that happens once the main page content is already displayed to the user
      • From a back-end perspective, you build that API to rely on a cache that proactively calculates the related items ahead of time
      • Together you can get the display to have nearly zero time cost versus the simpler version where it doesn’t exist.
  • To really work on performance you need to:
    • Create a problem that makes your application slow but demonstrates some kind of business value
    • Measure and prove that it is slow
    • Build and experiment with iterations to make it faster
    • Measure and prove that it’s faster
  • This is very common work for software developers. Making software that works is a basic expectation. Good developers make it work FAST.

Feeling Alive

  • The beauty of the modern web is that things don’t just happen on pageload
  • To see the animations and such that people can build in the browser are amazing, but really don’t have a lot of business application.
  • One great way to make an application feel alive to to set up competition across users.
  • If you were building an e-commerce app, implement a stock count of items. What happens when a competing user buys an item? Update the stock on the already-loaded page. Or maybe mark it as sold out.
  • When if you were building a ticketing application? I think about airline ticketing. What if other users are buying tickets at the same time? Or what if I’m browsing tickets while on the phone with customer support, and they issue me a credit and it shows up live on the page?
  • There are a lot of opportunities to bring a page alive without user competition.
  • The airline ticketing is an easy example where you can display a bunch of options to a user, then as they interact with the page selecting one option it can automatically do smart filtering.
  • Like say I’m booking a roundtrip ticket that flies from Denver to Las Vegas and back in the same day. When I select a departing flight that arrives in Vegas at 2pm then you could disable the return flights that leave before 2pm as they’re now irrelevant.
  • And on the sidebar you could display my “cart” that updates and I’m choosing different ticket options, showing the price of my current selections.
  • Then back in the main flight selections, you could dynamically display like “This ticket is $53 cheaper” than currently selected options.
  • When you imagine this kind of project, you don’t even necessarily need to build out a whole airplane ticketing application. You might just build out this one key part of the application and make it really good.
  • You’re just trying to demonstrate the technically interesting parts, not help someone run a fake airline.

Mobile First

  • Did you know that about half of web traffic in the US is from mobile phones?
  • Yet most projects treat a mobile interface as an afterthought
  • I’m not saying you need to build some React Native application — though that can be a really smart idea if it’s something you want to do.
  • But why not build some of your applications mobile first?
  • It’s a small set of constraints that can actually set you up for really interesting interactions
  • Particularly if you implement swipes, camera, or audio access
  • To make things perfect on mobile is a lot of work, but to make them “pretty good” is often not that hard when you use the right libraries.

Closing

  • Your projects aren’t going to win you a job, but they can win you an interview, and that might be enough.
  • You don’t need them to be conceptually interesting. This is not a startup competition where we’re looking for novelty of intent.
  • In fact you’re better biasing the other way. Build applications everyone already understands. Build applications they find a bit frustrating. Then figure out how to make them better.
  • And when you do all this hard work, you have to explain it. No one is going digging through your repos to try and figure out what made a project worthwhile.
  • You need:
    • a readme that makes sense
    • screenshots
    • graphs
    • demo videos
  • You’ve got to tell the story for someone to hear it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment