DEV Community: 30MP

10 Alternative Strategies for Landing Your Dream Software Development Job

30MP — Tue, 16 May 2023 23:02:07 +0000

The Strategies

This article is intended to help any software developer, from beginning to senior and higher, by providing some strategies to help land their next dream job. Now, not everyone has the same dream job—for some, their dream company may be Google, others may dream of working at a small startup—but this article will help you decide on some short- and long-term strategies to help you get that dream job. I'll start by listing out all the different strategies and then go a little more in depth for each one, explaining what it means and how it might be most beneficial—what it shows about you to potential employers.

Learn in public
Write a book
Sharpen your soft skills
Join online communities for a framework or language you like working in
Contribute to Open Source
Dive deep into a particular product
Attend local events
Attend conferences
Get certifications
Consider getting a higher degree

Learn In Public

You may have heard this phrase tossed around but not understood exactly what it means. In short, learning in public is the idea of learning something and posting or sharing publicly about the process as you go. The idea itself doesn't have a specific execution behind it, especially now with so many ways to share content. When I first started with my own learning in public, there was really only one way to share what you were doing, and that was by blogging about it. I would choose a topic or something I wanted to learn, I would figure it out, I would take notes, and then finally, I would write up a blog post about what it was I had learned. I typically did a tutorial style post where I walked people through how to use a tool or setup a project in a new framework, that kind of thing. Now there are several ways that you can share your progress.

Blogging

Blogging is a tried-and-true method for learning in public and raising your public profile. While it is more difficult now to get eyeballs on your blog, there are also other platforms out there that can help, such as Medium and Dev.to. I personally lean more towards Dev.to, as that is more of a community, and it allows you to post from your domain directly to a Dev.to site with minimal work. It's also geared more towards developers, so you’ll find an audience there more quickly than you will with something like Medium.

Video/Screencasting

This is another avenue to learning in public if you like to do videos versus writing out a lengthy blog post. Videos can take more work, but if done well, can be easier to follow for some people. There are a variety of platforms to choose from but, YouTube is the most popular.

Livestreaming

Another option I've seen is live-streaming your coding experience on a platform like Twitch or YouTube. Some stream it on Twitch and then share the recording on YouTube afterwards.

Sharing your code

When it comes to actually sharing your code, you have a few options available to you now, such as GitHub, GitLab, and Bitbucket. Or, if you crave having some kind of interactivity to it, you can use tools like Codepad or CodePen.

What this shows

Here are some of the things you can show prospective employers by doing this:

How you communicate
How you can explain complex topics and code to other software engineers (and maybe even beginners/non-developers)
Your thought process as well as some technical skills

Write a Book

This is a bit of a bigger undertaking, and one I wouldn't recommend until you've managed to get a few blog articles under your belt so that you feel you're ready to try and tackle a book. Most people who have written books are typically other developers just like you who took the time to dive deep into a particular framework or language and then turned around and tried to teach that to other developers or helped out with that project in significant ways. Writing a book can pay dividends well into the future. It's been a number of years since I wrote several chapters in one book and another book on my own, but I will still run into people in the industry who recognize my name.

Before you decide to tackle a book I would recommend:

Picking up and reading through the books that helped you learn something
- What journey did they take you on as a software engineer new to the topic?
- What fundamentals did they teach?
- What did they assume you already knew beforehand?
Try writing an outline for the book you would want to write
- Share this with other developers—did you miss anything? Did they suggest a different order of things?
Research that space
- Are there already books written on that subject? Are they missing something key? How long ago were they published? Did they sell well?
- What is the potential size of your audience? Before you say "All developers" really think about it and come up with a realistic number. How many are on the mailing list, forum, or message group (Slack, Discord, etc.)? Those people are probably your first target audience, though not necessarily all of them.
- How many different books are there on the subject? In developer publishing, there are around 5 - 6 different publishers. Do they all have a book on this? Or just one publisher? If 2 or 3 do, then maybe one of the other ones would like to have a book that covers this topic as well.
Prepare a book proposal with an outline (the tech publisher Manning has a proposal template you can look at to get started)

What this shows

Writing a book is a big undertaking, and ultimately it shows quite a lot about you. In addition to demonstrating that you can work with someone who is critical of your work (e.g., editors may request several revisions to make the book better), getting a book published shows that you have:

The ability to stick with and finish a large project
Good communication skills
Critical thinking and organizational skills

Sharpen Your Soft Skills

Soft skills can encompass a lot of different things, but when a tech company typically talks about soft skills, here is what they mean:

Communication—the ability to express yourself coherently and succinctly to others, which includes not only other software engineers, but quality assurance testers, project leads, and members of external teams.
Interpersonal skills—the ability to not only communicate but also listen and understand where someone else is coming from.

As engineers, we can struggle with getting a point across to others, especially if they are non-technical. Sometimes, you can use analogies to help them understand what you're trying to explain. Other times, we may not be completely listening before we jump in and start explaining things—in other words, you aren't allowing the other person to finish their thought. This can lead to friction between coworkers and prevent the free flow of ideas.

This is probably one of the trickier things to work on, but you can always start by asking friends if you tend to interrupt them when they're telling a story or trying to get a point across to see how your listening skills are. You can also practice on your non-technical friends by seeing if you’re able to explain what it is you're currently working on—get it as simple as possible so that they have a basic grasp of the problem you're solving and how you're solving it. Always an interesting exercise. If you're at a meetup or networking with someone, ask them to explain what they are working on and then attempt to tell it back to them, "Oh, so you what you're doing is similar to..." and then replace it with an analogy.

What this shows

During the interview process, you can talk about what you've been actively doing to improve your communication and interpersonal skills, and share your progress and what you still feel you need to work on. This shows that you're interested not only in your technical growth but also your growth in other areas.

Join Online Communities for the Framework or Language You Like Working In; Become a Resource

Online communities have exploded since I first started my career path as a developer. Originally, communities were limited to online forums, mailing lists, or IRC channels. In some cases, these have been replaced by Slack, Discord, Whatsapp, Telegram and other services. But the benefit is still the same.

Joining is the first step. The next step is to start answering questions that other developers are having. If you can't answer a question, then follow along and see what the answer is. Jot it down somewhere so you have it easily accessible. Then you can start asking your own questions. Be sure to pay attention to the group guidelines and search through older questions (if available) to see if your answer is already there. Practice your documentation skills here by spelling out exactly what you're expecting, what's actually happening, what you've tried, where else you've searched, etc. All of these things show that you understand that everyone's time is valuable and that you respect it. If you get an answer that may be terse or brusque, the first rule is simply this—don't respond right away. Take a breath. Take another breath. Maybe a few more. Re-read the response. Did they not understand your question? Did you miss a step somewhere? Did you forget to state something you had tried? Calmly respond to them with, "Oh, I'm sorry, maybe I didn't state it clearly enough..." or "Oops, I forgot to mention that I had tried that, and this is what happened..." Once you get through enough of these types of interactions, you get past the stage of being a newcomer to the group, and you can be a positive resource for other newcomers. Help them ask the right questions. Help them learn how to research problems.

What this shows

You know how to properly research and solve issues that you run into
You know how to communicate in a well-thought-out manner
You know how to explain a bug or issue to someone else in a step-by-step way so that it's easy for them to reproduce should they need to
You can become a resource to others to help them

Contribute to Open Source

This is a natural follow-on from the previous technique. Once you have started getting involved in the online community, you may be ready to actually contribute to the project as a whole. Now, this doesn't necessarily mean that you're dropping code right away; you could be helping with documentation, testing out new builds, or participating in discussions relating to new features. Open Source is one of those areas that, no matter which project you choose to participate in, you will probably be welcomed. It's always difficult to find people who want to help.

What this shows

Similar to working at a job, working on Open Source shows that you can work with a team and that you can work asynchronously.

Dive Deep Into a Particular Product/Project of the Company You Want to Work For

Is there a dream company you want to work for? Or maybe a specific product you want to work on? As a job seeker, a good way to get there is to become an expert in that tech company or tool, learning as much as possible. Where did the idea for their product or company come from? How long have they been in business? Is there any aspect of the products they make that are Open Source (if so, dig through that source code).

What this shows

This shows that you are invested, especially if you're active on their forums, or have asked questions elsewhere, or even better, answered some questions elsewhere. Sites like Quora or Stack Overflow tend to be full of questions from developers on how to do something with a particular piece of software or library. Seeing what problems other people are running into may give you some ideas on where the company can make improvements.

Attend Local Events

There are a number of local events that you can participate in to connect with other developers, find out what they're working on, or what local companies are building. Examples of events to look for include:

Software development meetups
Hackathons
Startup weekends

This technique is primarily about networking, connecting with fellow developers or businesses. Use the time to find out what others are working on, what kinds of tools, languages, frameworks, etc. are they using.

What this shows

It's possible that you could find your next job here or find someone that can introduce you to your next job. Hackathons and startup weekends are especially fun, as you and a small team collaborate to get something ready for demo in a short period of time.

Attend Conferences

Attending conferences can be a great way to land your dream software development job. This is because conferences are typically attended by industry professionals, including recruiters and hiring managers, who are looking for talented individuals to join their team.

When attending a conference, come prepared with business cards and a polished elevator pitch that highlights your skills and experience. This will make it easier for you to network and make connections with potential employers.

Additionally, attending conferences can help you stay up to date with the latest trends and technologies in the industry. This will not only make you a more knowledgeable candidate, but it will also show potential employers that you are committed to your profession and passionate about staying current.

Some conferences even offer job fairs or career events, during which you can meet with recruiters and hiring managers in a more formal setting. Take advantage of these opportunities, and make sure to follow up with any contacts you make after the conference is over.

Overall, attending conferences can be a valuable strategy for landing your dream software development job. It allows you to network with industry professionals, stay up to date with the latest trends, and potentially meet with recruiters and hiring managers in person.

Get Certifications

One of the most effective strategies for landing your dream software development job is to get certifications. Certifications are a way to let potential employers know that you have the knowledge and skills necessary to excel in your field. They also demonstrate your commitment to ongoing learning and professional development.

There are many different certifications available for software developers, depending on your area of expertise. For example, if you specialize in programming languages, like Java or Python, you may want to consider certifications from organizations like Oracle or the Python Software Foundation. If you focus on web development, certifications from organizations like Google or Microsoft can be valuable.

When choosing which certifications to pursue, it's important to consider which ones are most relevant to the type of job you want. Look at job postings for positions you're interested in and see what certifications are listed as requirements or preferred qualifications. This will help guide your decision-making process.

Once you've earned your certifications, be sure to highlight them on your resume and in your job applications. This will help you stand out from other candidates and demonstrate your commitment to your profession. Additionally, many certifications require ongoing education and renewal, so be sure to keep your certifications up to date to maintain their value.

Consider Getting a Higher Degree

One strategy to consider in landing your dream software development job is to consider getting a higher degree. While a bachelor's degree in computer science or a related field is often the minimum requirement for many software development positions, having a master's or even a PhD can give you a competitive edge.

Not only does a higher degree demonstrate your commitment to the field and your willingness to invest in your education, it can also provide you with specialized knowledge and skills that make you stand out from other candidates. For example, a master's degree in software engineering can give you a deeper understanding of the software development process and the ability to manage large-scale projects.

Additionally, having a higher degree can open up opportunities for more advanced positions with higher salaries and greater responsibility. It can also make you a more attractive candidate for leadership roles, such as project manager or technical lead.

Of course, pursuing a higher degree requires a significant investment of time and money, so it's important to weigh the costs and benefits before making a decision. However, if you're serious about landing your dream software development job and advancing your career, getting a higher degree may be a worthwhile strategy to consider.

Conclusion

Landing your dream software development job can be a challenging task, but it's not impossible. By utilizing the alternative strategies mentioned in this article, you can set yourself apart from the competition and increase your chances of getting hired. Remember to tailor your approach to each job opportunity and always be willing to learn and adapt. With persistence and a positive attitude, you can achieve your career goals and land the software development job of your dreams.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tips for preparing for software development interviews

30MP — Thu, 24 Feb 2022 21:21:25 +0000

Preparing for software development interviews

Preparing for software development interviews can be daunting. After all, you want to make a good impression and showcase your skills to potential employers. But don't worry – with a little preparation, you can ace your interview and land the job you want. Career Advancement is really easy to achieve if you can get the right job. This article will go through some of the pointers that will help you do well at your software development interview.

Typical Interview Process

1) Technical Pre-screen

The first step in the interview process is usually a technical interview pre-screen. This is a phone call with a recruiter or engineer to see if you are qualified for the role. They will ask you some basic questions about your skills and experience.

2) Take-home project

If you make it past the pre-screen, you may be asked to do a take-home project. You will have to complete this project at home and send it back to the company. This project aims to see if you have the software engineering skills required for the role.

3) Onsite Interview

If you pass the technical pre-screen, you will be invited for an onsite interview. This is usually a full day of interviews with different people from the company. You will likely be asked to do a coding challenge, interview managers, and maybe even have a lunch meeting.

4) Boss interview

Another type of interview is the 'boss' interview. This is where you will meet with the department head or division in which you would work if employed at that company. They are usually pretty informal, so just be yourself!

5) There may be more interviews

The interview process can vary from company to company, so there may be more or fewer interviews than what we have listed here. But the ones we have mentioned are the most common.

Types of questions

1) High-level technical interview questions

Companies are looking for people who can work at a high level, so you will most likely be asked difficult questions. Some examples of these types of questions are:

How would you design a system that sends an email to a user that has just signed up?
What is the normal signup flow that you might find in a web application?
What's your favorite open-source project and why?

2) Language/Framework specific questions

If you are interviewing for a role that requires specific language or framework skills, you will likely be asked questions about that language or framework. For example:

What is the difference between arrays and lists in Java?
How would you implement a queue in Ruby?

3) Behavioral/Team questions

Behavioral or team questions are the most common type of question asked in interviews. The purpose of these questions is to find out how you work in a team and what your strengths and weaknesses are.

Some examples:

What is your greatest weakness?
Tell me about a time when you had to go above and beyond the call of duty at work.

4) There could be a coding challenge on-site

A coding challenge might be part of an on-site interview or a take-home project. It will probably be time-boxed (e.g., 2 hours) and should allow you to write some code that works. You will most likely be asked to walk through the code and your thought process.

Whiteboarding questions

1) How to sketch out the problem

When whiteboarding coding questions, it is important to show the interviewer that you can work through problems. You don't want to write code or point at the computer and say, "I'm working on this." It is good practice to work through parts of your problem on paper before writing any code. Here are some ways you can do this:

Ask clarifying questions about what they want if you're unsure (e.g., How many points should be in your Fibonacci Sequence? What will these points represent?).
Start with pseudo-code (e.g., Pseudocode for Fibonacci Sequence)
Draw shapes representing arrays/lists/stacks/queues

2) Think out loud

This is especially important when you are stuck on a problem. The interviewer wants to see how you think through problems, so talking aloud will help them understand your thought process. Some things to keep in mind:

Don't be afraid to ask for help
If you get stuck, take a breath and try to think of another way to approach the problem
Explain your thought process as you go along
If you end up solving the problem a different way than what they were looking for, explain why you made that decision

3) How do you address the problem

During your whiteboard session your interviewers may throw different questions at you to see how you handle changing requirements or to probe your solution for possible weaknesses you may not have thought of. How you answer these new problems will definitely play into your overall impression you leave them with.

Behavioral/Culture fit questions

1) Your strongest skill/weakest skill

One of the best ways to answer behavioral questions is to use the STAR technique. This stands for Situation, Task, Action, Result. Here's an example: Tell me about when you had to deal with a difficult customer.

Situation : I was working as a cashier at my previous job, and I had a customer who was angry and yelling at me.

Task : I remained calm and tried to listen to what he said.

Action : I apologized and offered to refund his purchase.

Result : He ended up leaving the store without any further incident.

2) How have you grown in your career?

This question is a great opportunity to talk about your software engineering strengths and how you've developed as a software developer. Some of the things you could talk about include:

Taking on new challenges
Learning new programming languages or frameworks
Being a mentor or teaching others how to code

3) What project are you most proud of and why?

This is one of my favorite questions to ask and be asked in an interview. It gives me a chance to talk about something that I'm proud of and to explain to them why. Talk about a project where you showed initiative and determination to get results. You should also explain how you contributed to the outcome of the project. You want to show them that you are a team player but can also work independently.

4) What is the most challenging thing you worked on?

The interviewer is looking to see how you handle difficult situations. Talk about a project where you faced many challenges but persevered and overcame them. Explain what you did to get through the tough times.

5) What was a project that went badly, and what was your role/what did you do on it?

Trying to identify weaknesses is a big part of the interview process. Talk about a project where things didn't go as expected and what happened.

How did you feel about it?
What could you have done differently?
Was it due to something that was out of your control?

6) How do you handle interpersonal conflict?

This question is looking to see how you work with others. Do you stay calm and try to resolve the issue, or do you get defensive and argumentative? You can also talk about how you've handled working in a team before or if you have experience leading people. It isn't a bad thing to talk about reacting in a negative way during a situation as long as you learned something from it and were able to show how you have grown since then. No one is perfect and most companies will appreciate the honesty, especially as you have shown how you have grown or how you might handle a similar situation now.

7) How do you handle criticism?

This is another question about how you work with others. Do you take feedback well and try to improve or get defensive? The interviewer is looking to see if you can learn from your mistakes.

Questions you should ask

1) How to research a company

It's important to do some research on the company before the interview. You want to be able to talk about their products, their mission, and what they're looking for in a candidate. You can research a company by looking at their website, LinkedIn, Glassdoor, and AngelList. When researching a company you should be looking for things like:

What are their main products? Can you sign up for it to test it and play with it? Either way right down your impressions of that.
What do they talk about on LinkedIn? Can you identify any people you might be working with? If your own profile is getting hits from individuals at the company go read up on them.
Do they have any posts on Twitter, Instagram, etc. what do they like to talk about there?
What do the reviews on Glassdoor say about them? Anything of concern come up that you want to bring up during the interview? Write it down.
Have they posted on AngelList (angel.co)? Have they outgrown AngelList? It's interesting to see where companies started out if they've grown bigger.

2) Typical questions that give you a day-to-day look at the company

It's important to see if the company is a good fit for you. Asking questions such as:

What kind of work will I be doing?
How do employees at your company spend their day?
What is the work/life balance like here?

3) What will your role be? What is expected of you? Who will you report to?

These questions are important to ask so that you understand what the company expects from you and ensure that what they're asking fits with your expectations or skill set.

4) What other departments will you typically work with?

You want to understand better what you'll be working on and who you will be interacting with on a regular basis.

5) How long have people been in their roles?

This question will help give you an idea of the industry's average job tenure. The interviewer may also talk about how long they've been with the company, which is a good indication that they're happy there.

6) New position? Or replacing someone who left/was fired?

This question will help you determine if the company is growing or in a state of turmoil. If they've just opened the position, it's a good sign, but if they're constantly replacing employees, it might be a red flag.

7) Typical hours/schedule

You want to know what to expect so you're not caught off guard. If the company has a lot of overtime, that might not be the best fit for you. Or if they require weekend work, you'll want to know that in advance.

8) Remote? Flexible hours? Work from home?

You might be interested in a specific position or the company's culture in general. No matter what it is, make sure you ask questions about important things to you.

9) Internal advancement?

This will give you an idea of whether or not you'll be able to move up the ladder. It's also useful if they're hiring for a position that requires management; you want to know what kind of career growth is possible.

10) Any interesting benefits?

This question is a great way to learn about the company's culture. Do they have a lot of team-building events? Are there free lunches and snacks? This is also a good opportunity to ask about parental leave, remote work, and flexible hours.

11) Growth opportunities/training?

It's good to know if the company invests in its employees. If they offer regular training and development opportunities, that's a good sign. It shows that you can expect to grow within the company and learn new things.

12) What are their core values?

This is a good way to understand what matters to the company. Does the interviewer talk about work ethic, integrity, and honesty? Those are all great companies values. If they're more focused on profit, that might not be the best fit for you.

13) Do you have any reservations about my qualifications or background?

If you feel like something is holding you back from landing this job, it might be time to address it head-on. Be honest with yourself if there's anything out of character in your resume or portfolio that could raise flags for employers. Your interviewer will appreciate honesty, even if it means leaving without an offer if things don't seem to fit.

Other preparations

1) Mock interview

Mock interviews are a great way to prepare for software development interviews. They help you become comfortable with the process and familiar with the types of questions that might be asked. You can also get feedback from a friend or family member, which will help you improve your interviewing skills. There are services out there that offer mock interviews, or you can have a friend who's done a lot of hiring help you out.

2) Mock questions

Make a list of questions about your experience, past jobs, and personal projects. Then read them out loud and answer them as naturally as possible. This is an exercise in understanding how you sound when talking about yourself and what you've achieved while working at different companies. It would help if you also asked your friends or family members to provide feedback to improve your interview skills.

3) Mock whiteboard sessions

Whiteboard interviews are notoriously difficult, but they're also a common practice. The best way to prepare for them is by practicing on a whiteboard. Draw out your ideas and designs, and explain your thought process aloud. This will help you get comfortable with explaining your work and defending your decisions.

4) Coding challenges

If the company you're interviewing with asks for coding challenges, it's important to be prepared. Have a portfolio of your best work ready to show off, and be prepared to answer questions about your code. Be sure to explain your thought process, what you were trying to achieve, and how you would improve your code.

In conclusion, there are many important things to consider before accepting a job offer. Salary and benefits are both extremely important, but so is company culture. By asking the right questions, you can better understand what it'll be like to work there day-to-day. When in doubt, be honest with yourself and your interviewer about your qualifications and concerns. The above tips will help you in your interview preparation.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Using Challenges to Build Habits

30MP — Tue, 15 Feb 2022 20:58:45 +0000

Using Challenges to Kickstart Learning Habits

If you’re struggling to figure out the best way up your skills as a developer, you already know that learning a new language or adopting a side project can help expand your skill set. But sometimes it’s hard to know where to start. Challenges are a great way to kickstart your way into making learning a new habit.

Whether you call it a daily challenge, a streak, or a code chain, the idea behind these challenges is to let you bounce around and try a few things. The two typical challenge lengths you’ll see are 30 days and 100 days, and that’s for specific reasons. With 30 days, the duration is handily a month long, so it has a nice feel to start at the beginning of the month and finish at or near the end. Furthermore, it’s often said that it takes 30 days to establish a new habit. As for the 100-day challenges? Those are a longer commitment that can be a good litmus test for whether or not you’re finding something interesting and engaging enough for you to stick with longer term. The quarterly length also allows for a good look back your progress and accomplishments.

Recommended 30-day and 100-day challenges

Below are some challenges that might help you get going on something:

My advice? If you’re looking to get your feet wet and try something new, a 30-day challenge is ideal for fast, light, exploratory projects. If you’ve found something really interesting and want to dive deeper, give yourself a 100-day challenge and see where it gets you. Happy coding!

Coding problems and how to get unstuck

30MP — Wed, 09 Feb 2022 10:30:00 +0000

Help, I'm stuck!

As programmers, we will invariably run into a problem we just can't seem to think our way around. Maybe it's a solution we thought was elegant but actually led us down the wrong path, or maybe it was a seemingly simplistic problem that wasn't so simple after all. Beginning developers as well as experienced developers will all get stuck at some point or another. Whatever the case may be, it happens to us all. So let's take a look at some tactics to help us get moving again after hitting that coding wall.

Sketch it out

Sometimes it helps to sketch out what you're trying to accomplish. Sketch out all the systems, services, or pieces of code you will need to talk to and see what needs to happen along each step of the way. Until you can visualize what needs to happen, your brain may be struggling to help you find the solution you're looking for.

Take a walk

Other times, your brain may just need a little reset. When you've been locked in combat with, well, yourself, take a break. Go for a walk or listen to some music. These things can help your brain focus on something else instead of the problem at hand. Sometimes, this mental switch can help you utilize a different part of your brain to attack the problem and help you come up with a solution.

Work on some other aspect of the problem (or a different one altogether)

If you’re stuck on a particular piece of a problem but another piece is available to tackle, you can do that one instead. Working on something tangential can get your mind thinking about all the things that need to happen for the other piece. Or at least you won't feel like you're completely stuck and at least making some forward momentum on the larger problem.

Or another way to get your brain to shift gears and work on the problem subconsciously is to tackle a different issue altogether. This way you are still moving forward on things that need to get done and giving your brain time off so to speak.

Grab your ducky (or cardboard cut out)

This is one of my favorites problem-solving solutions, and it goes by several names--Cardboard Programmer and Rubber Ducking are just a few of them. How it works is fairly simple: if you don't have someone to explain your problem to, grab an inanimate object you can talk to--a cardboard cutout of someone, a rubber duck, a stuffed animal, whatever it might be--and start explaining your problem. Talk through the problem as if you were trying to explain it to a colleague. As you verbalize (or in some cases write down) your problem and possible solution, your brain switches into another gear.

As you do this seemingly simple act, you may hit upon the right answer to your problem. I used to have a supervisor that served as my "Rubber Ducky." Many times, I would walk into his office struggling to find the right solution to a given problem, typically within just a few minutes of explaining the problem and the issue with my solution, my mind would land on it, all without him having even said a word or asked a single question. Now, my development journal fills much the same role for me as I hold a dialogue with myself, going over the issues and how all the pieces will fit together.

Break down the problem into smaller parts and solve those first

Another option is to try breaking your problem into chunks. You may have started off with a large problem, for example: "We need to connect our new microservice into our payment service so that we can accept payments when a user signs up." There may be several questions that spring to mind:

How do I connect with the payment service?
What kind of data does it expect? What does it return?
How will I get the data from the user that I need to send to the payment service?

Once you've gotten a list started, then you can start to break it down even further. What kind of objects will you need in your service? What about making sure your methods are small enough to be tested?

Or maybe what you're stuck on is a complex algorithm. You are doing your best to write something that is elegant and performant. Maybe what you need first, though, is a big clunky thing that isn't all that performant but actually works. Having something that works helps you see where you can improve and refine and make sure it still works.

Write a test first

I'm a big fan of test-driven development, or TDD as its also known. With TDD, you start with a test first; you write a test against a specific aspect of your method, one that will fail first. You then begin to iterate on your code until you can get it to pass. Once it passes, then you move on to the next test you can think of for the next method, or a negative test (one that should fail). Keep iterating and building out your function, class, service, whatever it might be until you feel satisfied.

Oftentimes, writing the test first forces you to think through scenarios you would not have thought of in the beginning, and it guides you through changing your interface before you have a lot to change. Doing TDD also forces you to break your problem down to the simplest solution first that passes and then expanding on this.

Pair with another programmer

Pairing with another programmer is another excellent tool for getting unstuck. Much like Rubber Ducking, this forces you to first explain the problem, a possible solution, or an issue that you're having. Then the act of watching as someone else drives, stepping through possible solutions, can open up other avenues neither of you saw.

Wrapping Up

I've personally used all of these, some of them multiple times in a day. It helps to work through your problems with others, even if they're not real like the rubber ducky ;). No one of these is a given go-to for me; it always depends on the situation at hand as to which method I will choose. If no one is available immediately, I may write down my problem and solution, or talk it out out loud, or I might sketch out something on a whiteboard to try and poke holes in it. If someone is available, I might ask to do a quick Zoom video, or if we're in the same office, I might go over and chat with them in person, or grab someone to sketch something on the whiteboard together. Hopefully, these will help get you unstuck on whatever problem you've been having.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Regain Focus and Energy

30MP — Tue, 01 Feb 2022 18:40:36 +0000

Taking a break to do one of these activities can help shift your brain out of its current mode of thinking so that you feel reinvigorated. The idea is to engage a different sense, skill, or physical movement for 15 minutes to reset your brain.

Brain resetting activities

Listen to a podcast, audiobook, or new music
Write down 5 things you are grateful for
Write down you current roadblocks
Do a puzzle
Play a short video game
Doodle or draw
Meditate
Get moving by taking a walk or doing bodyweight exercises like squats or jumping jacks

Once you're done you are ready to set up your workspace again (seeMise en Place) and start a Pomodoro timer for 25 minutes.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Join the Conversation: Discord for Developers

30MP — Tue, 07 Dec 2021 21:40:50 +0000

Programmer's Hangout - General programming community
The Coding Den - Another general programming community
CodeSupport - Get support for your coding efforts
Buildspace - Get started with web3

Here are some more detailed lists that include some language-specific Discord servers (sadly some of the servers in these lists no longer seem active):

Top 10 Discord Servers (Devsurvival)

Discord Servers for Programmers (HiveIndex)

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Get back on track with goals

30MP — Thu, 02 Dec 2021 21:24:20 +0000

Getting off track

We've all had it happen to us at one point or another--we've gotten off track from our goals. Things were moving along nicely, and something broke our routine for that one day. Then life decided to intervene, and it turned into two days, then three, then...well, you get the idea. Now you're staring at what once was a nice long streak of consistent days working on your goals, and now there's this chasm. It can fill even the best of us with despair, maybe even a bit of depression. You had put in all this hard work and now? Do you just give up? Throw it all away? I've felt that way before; I certainly get the feeling. That simple idea, "Well, I had a cookie so now I'm just going to go ahead and have the gallon of ice cream, that burger, etc." It is a strong pull to just throw in the towel (at least for today, maybe tomorrow, too).

It sucks to lose that momentum, and once your two or three days starts stretching longer, you now have to re-break that inertial pull of, well, doing nothing. And it is hard to do. Hopefully these tips will help you break through that barrier that you’ve erected so you can get some momentum again.

Some tips to get going

Just 5 minutes

Just 5 or 10 minutes of X (whether it's writing, working out, meditation, whatever it might be). Just plan on that amount of time and do it. If you feel like going past 5 minutes, then keep going. If not, stop. Plan for 5 minutes the next day, maybe 10 minutes the day after. Move slow and be gentle on yourself.

One small task

Just one small task towards your bigger goal, even if that task is to figure out all the tasks that need to get done. Again, if you feel like tackling another small task then go ahead and do it. Same for the following day. Every little thing you get done helps you move the ball down the field towards the goal post.

Plan tomorrow

Make a plan for doing something the next day (if you’re on day 1 or 2 of missing stuff). Plan the day out, maybe plan out the next two days. You’ll work better when there's a roadmap in front of you and you have made a commitment to doing something.

DO NOT GO OVERBOARD

If it has been a week, or more, do not tell yourself, "I'm going to do 2 hours of writing today or tomorrow to catch myself up." NO. This will inevitably lead to failure and beating yourself up and possibly even ruining what would have been a successful kickstart to positive momentum. Review the first two tips - 5 or 10 minutes, 1 or 2 small tasks. Start slow. Get your feet back under yourself. Then keep moving.

Once you're back

Once you're back and have started gaining some momentum again, you want to prevent what just happened, but how? How do you prevent life getting in the way of your goals?

The real answer is you can't prevent everything, but you can have a plan for when it does happen and how to get your momentum going again.

Analyze what caused the problem initially

Now, I'm not talking about life getting in the way, but what happened afterwards. Why didn't you just pick up the next day and start again? Did you just not feel like it? Was it a lack of motivation? Was it feeling like you aren't making progress?

Here are some things to keep in mind with this analysis:

In order to maintain your motivation to keep writing, keep learning, keep getting better, keep working out, whatever it might be, you should have an emotional pull that helps you maintain that motivation. Maybe you don't have a very strong emotional tie to your goal. Losing weight isn't a strong motivator, but getting fit so that you can more easily play with your daughter is. Dig deep to help you find those emotional ties.
If you're feeling like you aren't making progress, there may be a few things going on. First, maybe you're not tracking the right thing that will help motivate you. If you have a goal of learning new languages and you're measuring how many coding challenges you can get through, you might be missing the reason why you started learning that language in the first place. What has it taught you about your own programming? Have you shared your knowledge with others? Has it helped you approach problems differently? Write down all the things that you have picked up along the way that you wouldn't have ordinarily.
Or maybe you aren't actively tracking what you have been learning. It can feel like you're spinning your wheels if you don't have daily or weekly check-ins with yourself to see what you're doing. Again, go back to your emotional why--why is it important that you do what you're doing? What kind of results are you looking for? How can you track those results? Maybe it's just simply, "Do I feel better after working out?" or, "Am I able to improve my press strength over a 4-week period?" Looking at the last might mean that you measure once before you start your 4-week set of workout and then once at the end. That doesn't mean you don't track each and every workout, but you are measuring against where you started.
Is this goal still right for me? Sometimes it just isn't. Maybe when you started out you thought that achieving this goal would help you in your job search, or help you learn that new framework, and those are no longer pertinent. Things change, goals change, priorities change. But if you blindly continue moving forward with something “just because,” you will eventually start to lose your motivation to do that thing.

Accountability

Another thing that can help is having an accountability partner (or group) that you can report to daily on your progress. Typically this is someone who is trying to achieve a similar goal, and you can help prop each other up on those down days.

You can also look to find a coach who will help you with the accountability as well as helping you define what goals are important and a plan for achieving them.

I would not recommend that you have a spouse or a significant other be your accountability partner, as this can place undue stress and wear on a relationship.

Moving forward

After building up your momentum, you will probably hit one of those days. Maybe life threw you a curveball, or maybe, even with every ounce of will you are trying to muster, you just can't get yourself to do the work. You, my friend, may need a break. We all do sometimes. Professional athletes do. Professional writers do. It happens. No one can be on 100% every single day or even 50% sometimes; everyone has their limit. Ask yourself honestly, "Do I just need a break today?" If your body begins to relax almost immediately, then the answer probably is yes, you most certainly do. Great, you've earned a break, take the day off, but before you do that, come up with a plan for what you will do tomorrow. Commit to doing the work, whether it's a reduced load or time or you feel you'll be ready to hop right back on. Whatever the case may be, make a plan and commit to yourself.

Now, if tomorrow comes and you again don't quite feel like it you may be heading towards a slump and you want to go back to the second section and analyze why. Are you goals out of whack? Are you not feeling motivated? Are you not feeling progress?

Now, this is where it gets to the heart of things. Maybe, just maybe, what you had as a goal is no longer what you really want. This is always a hard one. If it feels like your goal is no longer aligned with where you are heading then maybe you are going after the wrong goal. This may necessitate a few days off while you journal and think through things before making a final decision to either alter your goal, or dump it entirely.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Career-Stalling Habits

30MP — Tue, 30 Nov 2021 20:54:14 +0000

It can be easy to get yourself in a rut, but if you're aiming to advance and nurture your career, you need cultivate these common habits.

Career-Building Habits

Learn new things
- Employers love to see developers pushing themselves to learn new frameworks, languages, or techniques and will reward initiative (or another employer will).
Read relevant blogs
- Keep up to date with your industry and current position by reading relevant blogs so that you’re not blind-sided by a new technology, language, framework, or trend.
Engage with other developers
- Networking and engaging with other developers via social media or Meetups will help you stay apprised of current trends and news.
Improve your skills
- Don’t too comfortable in your current position without working to improve your skills continually, or you risk becoming irrelevant, the industry having passed you by.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

How scheduling your day completely helps you stay focused

30MP — Fri, 12 Nov 2021 15:58:18 +0000

Just tracking

I'll start this off by saying that when this was first suggested to me, I met it with a fair amount of resistance. There was no way that scheduling my day down to 15 minute blocks could help me. I'll just continue doing what I've been doing and keep track of my meetings and try and plug some big blocks in here and there. And that’s what I did until I came to the realization that I wasn’t actually scheduling anything; I was merely logging my work and was still hugely unfocused.

The focus problem

What I was doing wasn't working for me. My days were getting out of control, and I was finding it extremely hard to stay focused on the stuff I needed to get done each day. I was struck by the need to wait in-between blocks. "Why start something right now when I can't finish it? I'll just wait until after my meeting." My meeting would come and go, and I'd still be there, needing to take a "break." That break would last for 30 minutes, and then I'd try and get back into my flow. People with ADHD typically suffer much worse from this "waiting game."

Exploring some solutions

The Maker's Schedule

One examination of this problem was done by Paul Graham in his essay called, “Maker’s Schedule, Manager’s Schedule.” One problem I feel he illustrates so well:

"When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."

Having a developer attend a lot of meetings, or even a few meetings, scattered through the day, can indeed interrupt them and cause their train of thought to veer off course. So what are some solutions here?

Schedule meetings around the beginning of developer's days or around other breaks like lunch to take advantage of the break that has already occurred.
Schedule meetings in blocks next to each other if there are going to be multiple.
Have no-meeting blocks throughout the week (not just one day).

Unfortunately, some of these ideas begin to fall apart for some developers, especially those in lead positions, that have a lot of meetings to attend and have their days broken up.

No -m eeting days/blocks

Another possible solution is to have your day partially booked to begin with. This tells others that you are busy. Having No-Meeting Days are great, too, but relying on just one day a week where no one can schedule a meeting with you is problematic for a lot of reasons. Don't get me wrong, though, I love it when I have an almost completely day free of meetings. Those are my most productive days by far, as they offer me a lot of opportunities to focus.

The Rigid (but) flexible solution

This name is a bit of a misnomer as it isn't your schedule being flexible it is you. One thing I've been able to try and cultivate in myself is the ability to quickly get back into the zone when I've been interrupted by a meeting, a co-worker, what have you. I talk about some of these techniques in my blog post "Mise en place." Now, what can this do for you? Well, in combination with scheduling out your day, it allows you to be able to quickly, and relatively efficiently, switch gears to another task.

How to schedule your day (yes, even breaks)

Here are the general steps I take for planning out my daily schedule for my next day's worth of work.

Review my to-do list
Write down my daily goals, all the things I think I would like to accomplish for tomorrow (including project work, any errands or phone calls I may need to make, etc.)
Review my calendar for appointments and meetings I may already have
Try and guesstimate how much time each item may actually take to complete
Starting from when I wake up, go through and start mapping out my day with meetings being my segregation (including when I want to take my lunch break)
Start slotting in work blocks in 15, 30, 60, etc. minute blocks of time
I know that I like to work 60 - 90 minutes blocks and then take a 15 minute break
I also know that right after lunch, my energy levels are a little low, so I need a little boost. I like to do some meditation or a 15-minute walk or exercise

I write all of this down on paper for the next day after I've got it mapped out. I prefer this over a digital calendar because the act of writing it down helps me remember what it is I'm going to be doing and it's also a lot quicker for me to do it that way.

Example schedule

6:00 - 6:45 - wakeup and get child to school

6:45 - 7:00 - track my vitals

7:00 - 7:30 - breakfast

7:30 - 8:00 - morning pages

8:00 - 9:00 - workout

9:00 - 9:30 - shower

9:30 - 9:45 - look at to dos

9:45 - 10:00 - standup

10:00 - 10:15 - break

10:15 - 12:15 - current gig work (4 POMs*)

12:15 - 12:30 - break

12:30 - 1:30 - current gig work (2 POMs)

1:30 - 2:30 - lunch

2:30 - 2:45 - meditate

2:45 - 5:45 - current gig work (4 POMs)

*Pomodoros

Does this actually work?

Short answer is, yes, surprisingly. I've even tried it on the weekends because I was having the recurring problem of simply losing track of a whole Saturday and then feeling upset with myself because there was no way I could accomplish half of the stuff I set out for myself on Sunday.

You might be saying, "Yeah, but I bet he doesn't have any kids, or a significant other. It can't work then." I actually have a 6-year-old-daughter and a wife with a chronic illness. In my case, it takes communication with my wife to let her know:

What I want to accomplish on the weekends
Find out what she wants to try and accomplish
Come up with a rough schedule that works for both of us and ensures that we spend time with our daughter that's quality time

It actually can save quite a few headaches and miscommunications, but, like anything, it is a work in progress and we're all learning how best to implement it.

Addressing change

It happens, you're working on your ticket and someone pings you with an urgent problem on the server. You have to drop what you're doing and jump on it to see what's going on. Or your spouse calls in the middle of the day because something happened at school, etc.

So do you just throw your hands in the air and say, "Screw it! This day is shot!" I mean, yeah, you could. I know I've done it. I know plenty of people who have done it as well. And maybe that is the best solution, given a particular circumstance.

Another option is to deal with the issue at hand as best as possible. If it is going to take longer than 30 minutes or an hour, then you may need to assess your priorities for the rest of the day. One of the things that I do when I'm scheduling out my day is to make a mental note of what things have a higher priority over others. If there's stuff at the end of the day that if it didn't get done today it would be OK, as long as something of higher priority took its place. That last part is the key--something of higher priority.

Prioritizing Items

There are many ways to prioritize your todo items, so we'll only mention a few of the more common ones.

Work backwards

For me, I tend to use a big goal that I'm trying to accomplish for any given week. All other tasks are then below that one. I'm working backwards from what I'm trying to achieve and then prioritizing that. Now, it may be that I have a number of other smaller items that also need to get done each day, including meetings not related to the big goal for the end of the week. I try and slot those in around larger chunks of time devoted to accomplishing my bigger task. The sooner I get my larger task finished, the sooner I can move on to some other items that may have risen in importance.

The Four Quadrants

This goes by a few different names, "Covey Time Management Matrix" or "The Eisenhower Matrix" or "Urgent-Important Matrix," and divides tasks into one of 4 different groupings:

Urgent & Important
Less Urgent & Important
Urgent & Less Important
Less Urgent & Less Important

Roughly, these four quadrants break down into the following:

Do First
Schedule These
Delegate These
Don't Do

Kanban

This is less a style of prioritization and more of a way to easily see how much work you have to do in a relatively easy format. Kanban leaves your work divided into columns. Each column is only designed to "hold" so many simultaneous tasks before it gets overloaded (called Work In Progress).

To Do (your immediate list of things that are left to do)
Doing/In Progress
Done

Ideally, what should happen is this:

You have finished a task and moved it to your Done column.
You look over at your To Do column and decide which one is most urgent or important to do next and move it to your Doing column.
You then work on that item until you either finish it, or are blocked by someone else. If you get blocked and decide to work on another item go over to the To Do column and pick another item and you finish that or your other item gets unblocked.

Now, periodically you many be working on an item and then an "Urgent-Important" item crops up that has to cut across the top of your columns. It supersedes whatever it is that you're currently working on. There's a good overview of the whole process at Personal Kanban.

GTD (Getting Things Done)

GTD is another well-known prioritization framework that helps break your todo items into specific contexts, time, etc. and helps you figure out what makes the most sense to work on "right now" based on where you are physically (e.g., at home, work, running errands), what you're already doing, or what you may have available to you (phone, computer, etc.).

In Conclusion

While it may seem counter-intuitive, I have found that if you actually schedule out your whole day, it feels much more freeing than it seems like it would. This is honestly something that I still struggle with a bit. But every time I do it, I find my day goes much more smoothly than when I don't do it. I don't feel like I'm grasping as straws trying to figure out what I should be working on next--I already know because I went through the exercise at the start of my day (or the night before) so I know what’s important for me to accomplish that day.

For me, that is honestly a big part of it, being able to look back at what I was able to get done and have a sense of accomplishment for my day. It helps reduce my stress and improve my overall outlook as well.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Twitter Accounts to Follow

30MP — Tue, 09 Nov 2021 22:25:47 +0000

Not knowing where to join in the conversation can be hard, here are some developer-related Twitter accounts that might help you get started.

@noopkat

I first met Suz Hinton when I was working at Zappos and then I got to see her present. Hands down she is one of the best presenters I've seen. Currently she's working at Stripe on the developer tools but she also does some cool stuff with IoT.

@ashleymcnamara

Ashley Willis is Lead of Developer Relations at Microsoft Azure and really into Golang too.

@ASpittel

Ali Spittel is Lead Developer Advocacy for AWS Amplify.

@EmmaBostian

Emma Bostian is a software engineer at Spotify and creator of a course on tech interviews.

@Whykay

Whykay is a community organizer focused on diversity in tech.

@shanselman

Former full-time software developer, now program manager at Microsoft.

@codinghorror

Jeff Atwood is co-founder of StackOverflow and Discourse.org.

@spolsky

Joel Spolsky is founder of Fog Creek Software, Trello, Stack Overflow, Glitch, and HASH.ai.

@dan_abramov

Dan AbramDan Abramov is a software engineer at Facebook and co-creator of Redux.

@cdixon

Chris Dixon former entrepreneur and now tech advisor and investor.

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

How do you measure success in your learning journey?

30MP — Thu, 04 Nov 2021 17:16:31 +0000

Dive right in!(?)

When you're beginning any new endeavor, your first temptation may be to just dive right into it. I know. I've been there, again and again. But, before you start, it's a good idea to have a measuring stick of where you are starting from. Without truly understanding your starting point, you’ll have no way of understanding where you are, or what you've accomplished.

What to measure

When you are considering starting something new, it may help to actually consider what it is you want to measure first. Is it knowledge level? Is it something that you've built? Is it a feeling of launching something? Is it some other yard stick? Identifying what your end goal is can help you track your progress as you implement and learn new things. Here are some typical end-goals I have used to help me define my my measurement guidelines more clearly:

Building a new app with a new framework
Feeling comfortable enough with a new language’s core features to be able to explain it to someone else
Being able to do X, Y, and Z with a particular language or framework (this can take various forms)

Once you have begun to figure out what your final goal is, then you can start to figure out how to measure that goal. Let's take a few concrete examples so you can get a feel for it.

Learning a new framework

You've decided to pick up the latest front-end JavaScript framework for building web applications. What are your steps? How would you go about doing it? They might look something like this:

Find a popular tutorial on Framework X and go through that until finished.
Decide you like it well enough for a next step; find a book or more challenging tutorial on the framework and work through that.
Tackle one of your own projects using this new framework. (It helps to pick a project that is fairly well-defined and you’re familiar with all of its moving parts.)

Your success at this point has three main steps:

Finish the initial tutorial until you have a basic, but functional, application.
Finish the more in-depth tutorial or book.
Build your own application, quite possibly one that you've built before.

Now, at the end of all of this, you should probably have a decent idea of a few things:

The main pieces of the framework and how they fit together
What parts of the framework you don't fully understand yet and have just been taking for granted

You have a few choices now. Do you continue diving deeper into this framework? Do you like it well enough to devote more time to it (right now)? Have you satisfied your curiosity and now want to move on to something else?

Learning a new language

Now, learning a new language will probably be a bit different, and is, in some ways, much more challenging than a framework. With a framework, you are already familiar with how the language works; you’re just applying some new principles. But learning a new language, you are sometimes doing both, learning a new language and a framework simultaneously. This is a big mistake, one which I've done myself more than a few times. It's best to get through a language first, and then try and understand the framework. So, what might learning a new language look like?

Work through some of the basic language tutorials so you can get a feel for it.
- How do you build the language?
- What's the syntax look like?
- What's the formatting standard accepted by the community?
Done with that, you might move on to some code katas or dive deeper in to common constructs.
Then you might dig deeper into other language constructs that are wholly unfamiliar to you.
- If you are mostly from an OOP background, many functional languages do things in a unique way that are very different to what you're probably used to.

For this your yard stick might be something along the lines of "I can do X, Y, and Z in this programming language."

[Note: I have a list of challenge sites that can be really good for language learning]

Learning a new technique

Now, this one is a bit more tricky to measure, especially since learning a technique in itself is a little nebulous. What does that mean, technique? Learning a new technique encompasses a few things:

Taking advantage of, or exploiting, a particular language's built-in features to do something unique.
Learning a new computer science data structure or algorithm that you had not previously tackled.

Just to dive a bit deeper into this, I'll try and cite a few examples so you have a better idea. Language features that have been exploited:

In Ruby and Groovy, you can do what is called Metaprogramming, or the ability to rewrite programs on the fly.
- This also allows you to write Domain Specific Languages (DSLs) that sit on top of these languages.
In Lisp, you can also do Metaprogramming, but to a much greater degree, which also means much more in-depth DSLs.
In Scala, you have a few interesting concepts like Actors, Pattern Matching, etc.

These are just a few examples. So, what are some Computer Science (CS) techniques? Some of these you know, and use, but don't know how they were implemented:

Hash tables
Binary search trees
Heaps
Graphs
Sorting Algorithms
Search Algorithms
Dynamic Programming
Djikstra Shortest-Path Algorithm

How to measure

Now that you have a decent feel for what you're measuring, you may be asking yourself how you are going to measure your progress. In a more traditional learning environment, you may have things like quizzes and tests to help your teacher be able to measure your individual progress. Are you understanding the material? How do you compare to your peers?

Well, in the real world there are no tests, no quizzes, simply the question: can you use this to help accomplish a particular goal? And maybe a follow-up question of how quickly can you use this knowledge to accomplish this goal.

You might then choose to measure your progress by how much revenue your application makes (or saves depending your goal). But is this really tracking your own personal success? Possibly. It really depends on what you're trying to achieve. For me, personally, this doesn't really answer the true question of success, though. Have you failed if you've learned something through that failure? Have you truly succeeded if you haven't learned enough to repeat that success?

No, for me the true measure of success comes in a few forms, especially when it comes to learning something new:

Can I explain the core problem that a given framework, language, or technique is trying to solve?
Can I give another developer a 10 - 15 minute walk through of something interesting I learned and actually teach them something new?
Are there aspects of what I'm trying to learn that force me to think through problems differently?

Learning is an incremental thing; when you do it continually and consistently, you will gradually improve. But, and this is a big but, you must be methodical about it. Randomly diving into framework after framework, or language after language, without documenting your progress or what your particular goal is, may leave you feeling unfulfilled.

I like to think about measuring my progress as a daily, incremental thing. It has become a habit. I have a long-term goal that I want to reach, but if I am consistent and continually work on my project and goals every day, then I know I will get better at them, little by little. If I write every day, I will become a better writer. Same goes for coding. If I code every day, and focus on areas that I feel I'm weak in, then I will become a better coder.

Should you measure

The next question then becomes should you measure? For me, this is a bit of a misnomer. I have shifted from trying to focus on a specific end goal and started to focus on a daily goal. That goal being to work on my side project every single day. I have some other things that I like to throw in there like specific milestones for my particular project or actually releasing something, but overall my real goal, and the thing that I measure myself against, is my daily programming habit.

Within this habit, this is what I like to focus on:

Have I programmed for at least 30 minutes that day?
For this period (2 weeks, 4 weeks, 6 weeks, etc.) what am I focusing on? Anything specifically I'm trying to achieve?
Take copious notes on what I'm learning each day and where I would like to focus on for the next session.
Are there areas that I can apply this knowledge to elsewhere? Does my knowledge help me in other aspects of my work or life?
At the end of my block (2, 4, or 6 week) I look back and take stock of what I've actually accomplished. Can I write this up?

Wrapping up

Everyone approaches their learning journey in their own way. What I like to do is to be able to share my own journey with others as well as read about what others have done. Without this, I never would have come up with the concept of 30-Minute Project.

So, when it is all said and done, I like to try and share my own journey:

Where did I struggle? What did I do to get through that area?
What aspects of the framework, language, or technique did I really like?
What didn't I like? Or what might I change?
What are some of the good resources that I stumbled across?
- Blog posts, mailing lists, Slack groups, Reddit groups, documentation, etc.
Will I continue doing more with this? Why or why not?

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

Tuesday’s Tip – Join The Conversation

30MP — Tue, 02 Nov 2021 18:10:22 +0000

Whether it’s on Twitter, Facebook, LinkedIn, Reddit, Slack or Discord community, or some other community platform, make sure your voice isn’t missing.

Tips on getting social:

Join a community, start following relevant people, and introduce yourself
Follow along with the conversations, but don’t join in yet (unless asked)
Once you start to feel comfortable, start adding your voice to the conversation

Engaging with others, even in online communities, can help expose you to different ways of doing things as well as expanding your knowledge base. They can also be a great place to share struggles you may be having at work in a more anonymous or safe environment (be careful with this, though, as you may not know who is listening to your supposed “private” conversations).

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project

DEV Community: 30MP

10 Alternative Strategies for Landing Your Dream Software Development Job

The Strategies

Learn In Public

Blogging

Video/Screencasting

Livestreaming

Sharing your code

What this shows

Write a Book

What this shows

Sharpen Your Soft Skills

What this shows

Join Online Communities for the Framework or Language You Like Working In; Become a Resource

What this shows

Contribute to Open Source

What this shows

Dive Deep Into a Particular Product/Project of the Company You Want to Work For

What this shows

Attend Local Events

What this shows

Attend Conferences

Get Certifications

Consider Getting a Higher Degree

Conclusion

Tips for preparing for software development interviews

Preparing for software development interviews

Typical Interview Process

Types of questions

Whiteboarding questions

Behavioral/Culture fit questions

Questions you should ask

Other preparations

Tuesday’s Tip – Using Challenges to Build Habits

Using Challenges to Kickstart Learning Habits

Recommended 30-day and 100-day challenges

Coding problems and how to get unstuck

Help, I'm stuck!

Sketch it out

Take a walk

Work on some other aspect of the problem (or a different one altogether)

Grab your ducky (or cardboard cut out)

Break down the problem into smaller parts and solve those first

Write a test first

Pair with another programmer

Wrapping Up

Tuesday’s Tip – Regain Focus and Energy

Brain resetting activities

Tuesday’s Tip – Join the Conversation: Discord for Developers

Get back on track with goals

Getting off track

Some tips to get going

Just 5 minutes

One small task

Plan tomorrow

DO NOT GO OVERBOARD

Once you're back

Analyze what caused the problem initially

Accountability

Moving forward

Tuesday’s Tip – Career-Stalling Habits

Career-Building Habits

How scheduling your day completely helps you stay focused

Just tracking

The focus problem

Exploring some solutions

The Maker's Schedule

No** -m ***eeting days/blocks*

The Rigid (but) flexible solution

How to schedule your day (yes, even breaks)

Example schedule

Does this actually work?

Addressing change

Prioritizing Items

Work backwards

The Four Quadrants

Kanban

GTD (Getting Things Done)

In Conclusion

Tuesday’s Tip – Twitter Accounts to Follow

No -m eeting days/blocks