Build momentum with these small projects that you can finish in an afternoon. Start, implement, and finish. Working through projects quickly will dramatically improve your self-esteem and skills.

00:00 Why quick wins are so important
00:35 Not for beginners
01:14 Connect Four
02:07 Build an API for public information
02:50 Deploy a dice roll Lambda
04:03 Create a simple mobile app
04:57 Real-time transit data feed
05:45 Build a live chat with websockets
06:40 Pull your financial data using Plaid
07:42 JSON load/dump in a low-level language
08:43 Visualize & analyze large data sets
09:36 Manipulate audio files
10:31 Do these projects quickly

I write an email every day for 2k software developers. Get on the daily list: https://bennettgarner.ck.page/youtube

This week on the podcast, I share my experience and insights on starting a consulting business.

Covered in this episode:

• How to find your niche
• Horizontal vs vertical specializations
• Product, service, or productized service
• How to acquire your first clients
• Scoping projects
• Pricing services based on value

Starting a consulting business is really hard! It won’t solve all your problems to work for yourself — in fact you’ll probably have more problems.

But it can also be really cool, if you can build a business that works for you.

I discuss the dilemma of whether or not to refactor code that may not have the best design.

There are always trade-offs involved in leaving messy code versus investing time in making it better designed. It’s not straightforward whether you should undertake a refactor.

Understanding the scope of the refactor is also critical. Your changes can have a big impact on future developers and the overall system. In the video, I provide a set of questions to ask oneself before undertaking a refactor and emphasize the need for collaboration with the team.

Ultimately, the goal is to ensure that refactors drive value and benefit both developers and end users.

Over-commented code is often more difficult to understand than code without comments. If you can avoid writing a comment then don’t. Let your code stand on its own!

Article: https://levelup.gitconnected.com/youre-commenting-your-code-too-much-and-other-controversial-thoughts-on-documentation-1ee617ed46af
Daily email: https://bennettgarner.ck.page

When you assume the junior title, you undercut your career & growth. You probably have what it takes - right now - to work as a full software engineer.

Site: www.developerpupose.com
Daily email to 2k developers: https://bennettgarner.ck.page

It happens to all of us.

The code you released creates an issue in production. The site is down (or part of it is broken), and you’re responsible.

But you’re not to blame!

While you should take 100% responsibility for fixing the issue and getting the site back up as soon as possible, don’t feel guilty about creating the issue in the first place.

Everybody makes mistakes. This is an opportunity to learn!

--
Get daily email updates from me: https://bennettgarner.ck.page/

Veteran developers go through an insulting interview process. The interviews usually happen one of two ways:

They ask for ridiculously time-intensive take home assignments
Whiteboard interviews that are useless for the candidate and interviewer

Let’s talk about the problems and why I recommend you turn down insulting opportunities.