Forem: Julia Seidman

Back At One - A Chart-Topping Approach To Your Job Search

Julia Seidman — Tue, 29 Nov 2022 11:56:01 +0000

I'm turning 40 this week, which means I'm old enough to remember both versions of the hit song "Back At One". If you remember the song, it's probably the Brian McKnight version that was a huge R&B/pop hit in 2000, but did you know it was also a No. 1 on the country charts for Mark Wills in the same year?

I have a mostly-useless ability to remember song lyrics better than anyone else I know (except my sister) and while I'm not sure I could sing the whole song from memory now, I definitely remember the chorus:

One, you're like a dream come true
Two, just wanna be with you
Three, girl, it's plain to see
That you're the only one for me
And four, repeat steps one through three
Five, make you fall in love with me
If ever I believe my work is done
Then I start back at one, yeah, eah-eah

You might be wondering, "Why is Julia taking us on this trip down memory lane? Is this even a good song? What kind of song includes a method with recursion and conditionals? This is not romantic at all!"

To the latter line of questioning, I would just say that two charts can't be wrong. This song is a classic, and I won't hear otherwise. And anyway, relationships take work, so some recursive tenderness is probably a good thing! (Though I'd argue that 1 through 3 aren't really steps at all - if this song was written in a compiled language, those lines would definitely throw some "not a method" errors.)

As for "why", one explanation is that I'm writing this post at 2:30AM!

Really, though, the point is that someone asked me if I would write a post explaining my approach to job hunting, and as I was thinking about it, it reminded me of this song. Then I needed an intro to the post, and here we are!

No more wasting time! Here it is:

The Job Search Cycle

Sing it if you can:

One, apply for some jobs and seek feedback.
Two, use that feedback to set learning/growth goals.
Three, make some progress on those goals.
Four, don't repeat steps one through three yet! You need to document your progress and update your job search materials!
Five, repeat steps one through four! You're going to have more success than before!
If ever you believe your work is done, then you start back at one, yeah eah-ah.>

A Bit of Background on My 'Why'

Perhaps you've heard the expression "Insanity is doing the same thing over and over and expecting different results." Something like that. Aside from being kinda ableist and inaccurate for discussions of mental health, I think it's a pretty solid description of a typical job search - it's practically the explicit strategy behind the 'numbers game' approach that so many people promote. But if you send our 499 resumes and get 499 rejections, why on earth would you expect the 500th one to be different? No wonder job hunting can be such a tax on people's mental health.

If you want different results, you need to change the inputs. If you want to make progress in your tech career, you have to make routine investments in your growth. It's a cycle, not a race to a finish line.

At the same time, it can be really daunting to try to figure out where to invest! If you spread yourself too thin, you won't get meaningful outcomes. That's why I think it makes sense to apply for some jobs now, wherever you're at - not because you'll necessarily get them, but because if you don't, you gain a great source of information to help you decide what you want to learn. It may be feedback from a hiring manager that helps you identify marketable skills, or it may be your own reflections on what kind of jobs really appeal to you.

Treating your job search as a cycle turns it into an intrinsically valuable and motivating set of activities. Rather than having a single goal - a job - and potentially spending hundreds of hours of time on unsuccessful attempts at that goal, you reframe the process around a series of achievable goals with measurable outcomes, and keep iterating, growing both your skill set and your self-knowledge and confidence in your direction.

An Instance of the JobSearchCycle Class:

When I was looking for my first job in tech, my main portfolio piece was a .NET MVC app for managing caregiver communications. One hiring manager I spoke to said he felt the framework was a little outdated and I wasn't ready following current best practices for dependency injection. I asked what would be a more compelling way to build the same application, and while he didn't really give me concrete ideas, he mentioned several things that were unfamiliar to me.

I decided I needed to do some more research on the topics he mentioned, which lead to my learning a lot more about other frameworks and design patterns. Along the way, I learned enough about Mongo that I was able to write a paid article about it, and I decided to commit more energy to learning Django and Postgres and less to .NET and mySQL. I updated my LinkedIn, my resume, and my freelance profile to emphasize Python/Django, and almost immediately began getting more contacts, which netted me a few interviews and my first job as a developer. Now, I actually work in-house for the agency that assigned me that Mongo article!

I applied for jobs, got feedback, set actionable goals for my own learning, made progress on those goals, then made sure my next batch of job applications reflected the skills I had gained. I also was applying to jobs that were more focused on work I really wanted to be doing, which I knew because I had already started doing that work on my own.

So embrace that "Back At One" spirit! Use your job tracker spreadsheets if you want, or don't if they make you crazy and despondent! The point here is growth, always. Progress, not perfection. Iteration on concrete goals, not intangible, unachievable standards. Brian McKnight puts his pants on one leg at a time just like anyone else. But my dude is still making music, and it's clear he knows the secret to making gold records is iterating towards a better version of yourself, one step at a time.

What Peloton Instructors Taught Me About Being a Dev

Julia Seidman — Tue, 22 Nov 2022 20:23:05 +0000

I got my Peloton bike two years ago, for my 38th birthday. My 40th birthday is right around the corner, and I'm about to hit 400 rides! I would have done a lot more by now if it hadn't been for a skiing accident that kept me off the bike for almost 6 months, but I'm not dwelling on that now! In fact, I would say my Peloton rides have played a crucial role in my recovery from that accident, both physically and mentally.

If you've taken a Peloton class, you know the factor that sets it apart from a standard exercise bike is the instructors. They are incredible people - they represent a hugely diverse set of experiences, cultures, and ideas. I've gotten a huge amount of inspiration from them, and I've grown more as an athlete and a person than I ever expected from a home fitness program!

I've also learned some things about being a developer, believe it or not. A few words of wisdom for devs, from Peloton instructors:

This is what it feels like to get stronger!

My favorite Peloton instructor, Emma Lovewell, sometimes shouts this out right in the middle of the hardest part of a workout. It's not an uncommon idea, but what really makes it connect for me is the timing - right in the thick of things, when I'm really uncomfortable, kind of desperate, and feeling like I might cry, quit, or explode, she's there to remind me that THIS - this moment, this feeling - is the moment when growth happens.

Discomfort isn't fun, but it's definitely part of the game for devs. We tend to spend a lot of our work lives right on the edge of what's familiar and comfortable, which means we tilt into discomfort and struggle A LOT. I didn't sign up for this career because I liked being uncomfortable, and there are definitely plenty of times where it feels like too much. Crying, quitting, and exploding all seem like real possibilities. I don't usually shout to myself at my desk, but maybe I should! I love the growth - what I did sign up for was learning. And THIS is what it feels like.

We practice for progress!

I'm not winning any Peloton leaderboards, let's be honest. Sometimes, I manage to be the top woman "Here Now", and I celebrate any time I crack the top 20% overall. I work hard, and I get really excited about beating my own PRs, but my partner is an ultra-runner who regularly cracks the top 5% of riders, so even in my own house, I'm not going to be winning any races.

But as Ally Love reassures me, we practice for progress, not perfection. That's true for writing code, too. If you ever struggle with impostor syndrome, remember that there's no such thing as perfect code, and no developer who knows everything. All of us - every single one - are moving forward one step at a time, starting wherever we stopped the day before. Nobody has reached some absolute standard of perfection for software developers, because it doesn't exist. You can't get there. You can keep growing and moving closer to your goal, improving over where you were yesterday. The only thing you need to do is just keep practicing.

Think SMART: Specific, Measurable, Attainable, Realistic & Timely.

Robyn Arzón is known for making some big, bold pronouncements - I have at least one friend who thinks she's really a little too much, but she'd be the first one to say she doesn't need everyone to love her. I love her, and all the reminders to polish my crown and remember who I am make me feel like a queen. But I think the best advice she has to offer is about goal-setting. This is a woman who is a lawyer, the child of immigrants, a T1D patient, an ultra-marathoner, and a Peloton VP - she knows goals.

Whether you're talking about fitness or your coding projects, the same advice applies to your goals - make them SMART goals and you will have a much better chance of achieving them. Generic goals like "get more fit" or "get better at CSS" are not going to magically come true. You need a plan, and you need to know if you're making progress so you can keep yourself motivated. "Go to kickboxing class Tuesday and Thursday at 5PM" is a SMART goal that will meaningfully contribute to your fitness. "Spend two hours every Sunday on my CSS class" is a SMART goal that will result in "getting better" at CSS. SMART goals are practical tools to help you make progress towards a better version of yourself.

Make modifications, not excuses.

This one is from Alex Toussaint - is the prescribed set of exercises not working for you today? That's okay, but it's not a reason to give up. Another quote from AT - "We don't have the luxury to quit." Sometimes, I get to a point in a workout where I am really struggling to keep up, and this is a reminder to just keep moving. Keep moving while you figure out what is going to work for you, and you won't lose ground. Make the progress you can make today.

This advice actually reminds me of something I heard from Rachel Lee Nabors, of the web comic Rachel the Great, and a developer educator for React and now AWS. I interviewed with Rachel for a position at AWS, and they focused a lot on one anecdote I shared about a project that had not gone very well. I was frustrated, because I wanted to talk about my successes, and felt like we were getting bogged down in talking about a project I wished I could forget! Then, a few weeks later, I saw a post they shared on LinkedIn - the first paragraph made that interview make a lot more sense:

You're rarely going to be set up for success at a job. The only people who are supposed to be set up for success are interns and juniors. After that, your effectiveness is measured by how well you pivot or deliver despite the odds when things are less than ideal.

Got it. This multi-talented, driven, and generous person was trying to find out how I handled it when I was not set up for success. Was I going to make modifications or was I going to make excuses? It's not that they didn't want to hear about my successes, it's that they wanted to know that I was going to continue to evolve and pivot so I could continue to deliver more success even when things were not going my way. Because that's what it takes - we don't have the luxury to quit if we want to keep moving forward.

If cauliflower can be pizza, you can be anything you want.

Cody Rigsby is the comedian of Peloton, and not known to hold back on his opinions or hide his light under a bushel. He speaks to a lot of people who are not "typical" athletes, and reminds us to love ourselves with "our whole ass, none of this half-assed" business. Cauliflower pizza is not for everyone, and you may not be to everyone's taste either. But if you want to be an athlete or a web developer or a public speaker or a Disney superfan, it is absolutely within your power and rights to be that.

Another Ally Love quote that goes along with this might ring truer to you - "Don't compare your Chapter One with someone else's Chapter Six." You are where you are today, but that doesn't limit where you can go tomorrow. If you want to learn something, you can. If you want to do a new kind of work, you can. Your path there won't be the same as anyone else's, but if you set some SMART goals that line up with that vision, you can get there. If you want to know how people got to Chapter Six, ask them to tell you their Chapter One. Chances are, they started out as the developer equivalent of cauliflower.

Don't rely on compliments for confidence.

Oof, right? I'm a sucker for compliments. But I also know that I'm going to get more confidence by reflecting on my own progress than from any external validation. Christine D'Ercole is a pretty remarkable person, and has spoken openly about escaping an unhealthy marriage and poverty. Relying on others to provide her self-worth was never going to work, and her stories of discovering her strength and investing in herself are inspiring. For me, and for her, athletic achievement is a big source of confidence.

Sometimes, when it comes to my work as a developer, though, I have a harder time remembering this idea. I work independently most of the time, and I don't usually get much feedback along the way. Now and then, a compliment from a client will get passed back to me, and I'm not ashamed to say I LOVE those moments! But I can't rely on it, because most of the time, there just isn't anyone else around to see what I'm doing, and when there is, they're usually preoccupied with their own challenges and needs. That's probably true for most of us, even on larger teams. We're all heads-down, plugging away on our own work, and compliments are few and far between. It's not because people don't appreciate your work or admire your strengths - they're just busy. Don't take it personally, but invest in figuring out how to build your own confidence, because you're not going to be able to rely on anyone else.

Hand on your back.

At the same time, you're not alone. D'Ercole is a competitive Master's division cyclist, teaches a series of classes based on big climbs from real rides. During these classes, in middle of a really tough effort, she'll sometimes say "Hand on your back."

It's taken from the way cyclists on a group ride support each other. Usually, the group will ride together on the flats, but when you get to the uphill, riders split up as each person digs into their own personal struggle. It's a time when you rely on the voice in your own head to keep you going, but sometimes, right when you need it most, you'll feel someone's hand on your back.

That gentle push probably doesn't do much to actually get you further up the hill, but the knowledge that someone else is coming up behind you, looking out for you, watching your progress - that is powerful stuff.

Know that's true on your journey as a developer, too. People may not be coming out of the woodwork with compliments, but they are there, watching you, admiring your effort, seeing your progress, and ready to put a hand on your back when you need it.

So keep pedaling, one foot in front of the other, stronger every day. Together, we go far.

I Want to Help You Write!

Julia Seidman — Tue, 15 Nov 2022 22:28:18 +0000

A while back, we had a client who wanted to create a Write For DO-style program. They wanted to start small, with "warm" contacts, and provide some basic editorial guidance to help people get started. It never really got off the ground, because they didn't put enough resources behind it, and because it's HARD to get busy people to set aside time to write.

As part of the project, I created a couple of "How To" guides - not "How To Build a Yelp Clone" or "How to Integrate Snowflake in Your React App", but "How To Write" guides. I created two, one for detailed tutorials, and the second for technical opinions.

I came back to these recently in preparing for the November Monthly Challenge with Virtual Coffee. The challenge is modeled on NaNoWriMo - as a group, we're trying to write 100,000 published words in the month of November. I offered to update those guides and tweak them for the VC community, and then I thought I might as well share them with everyone! So, here they are!

I'm offering these with a couple of caveats:

First, I would much rather have you write something than get hung up on achieving perfection. These guides are intended to be inspiration and to help you "level up" if you want to. No requirements!
Second, these are based mostly on my experience, and might not reflect everyone's preferences. I'm not trying to prescribe anything, just suggest an approach that works for me that represents generalized good practices.

I'll share each of the two guides in a separate post - let me know what you think and if they help you in any way! If you use them, I'd love to get a mention when you publish!

Why Do You Do It That Way?How To Share Your Technical Opinions So People Will Listen

Julia Seidman — Tue, 15 Nov 2022 22:27:13 +0000

We’ve all heard enough “hot takes” to boil a pot of water, but opinions that are expressed memorably and compellingly are a much rarer commodity. If you think you have a perspective people should hear, a purposeful approach is going to get you more buy-in than a spontaneous flood of tweets.

This guide is to help you write articles that explain WHY you recommend a particular technical approach. You don’t need extensive code samples. The goal is not for readers to be able to reproduce a specific feature, but to be able to make more informed choices in their future work. Get as concrete and specific as you can about the work you’ve done that shaped your thinking. Dig into pros and cons of different options you’ve considered and explain the logic behind your opinions.

In terms of Aristotle's rhetorics, i.e., the art of persuasion, you need to build some ethos. Establish your credibility on this subject in ways that will appeal to readers. Many writers focus on logos, or logical appeals. Obviously, you need to share reasons behind your opinions, but avoid the temptation to “out-logic” the other side. We all know there’s rarely a single correct technical solution to a problem, but it can be hard to sort out high quality advice. Your unique perspective and experience are the most valuable resources you have. Don’t be arrogant, but show readers why they should pay attention to your voice.

Overview

Give your idea shape with examples and framing questions
Plot the path ahead - brainstorm and outline
Fill in the details of your unique story
Seek feedback and revise
Publish on your blog or other site

1. Define and Shape Your Idea

Get Inspired By A Few Good Examples

Consider what works for you as a reader and learner in these examples:

Start With Framing Questions

What is the problem you are focused on? What human-centered use case illustrates the problem?
Who are you talking to? How is your advice going to make their lives better?
What background knowledge does a reader need to understand your main idea?
What background knowledge and experience do you have that shaped your conclusion?
What are the alternatives? Did you try them? Why didn’t they work? Or why did you not even try?
What are the drawbacks of the approach you’re recommending?
Did you change your mind about any aspect of this problem and/or solution? Or did things go exactly as you expected?
How certain are you about your conclusions? What would make you change your mind?
Who else would benefit from taking your advice? What kind of projects?
How will you put your principles to the test in the future? What else do you need to investigate?

2. Plan Ahead to Tell A Clearer Story

Your high school English teacher was right — a little preparation can make your writing process a lot more successful. The effort you invest in an outline pays off when it’s time to write the article, especially if you won’t be writing your entire draft in one sitting.

Learn From Debaters

Let’s assume you’re already planning to provide evidence for your arguments. Take it a step further and make it relevant to your readers with a model used by debaters. You have a thesis – your main idea, your central opinion, however you’d like to frame it. You probably have a few reasons to back it up. We’ll call those “Claims”. For each Claim, you should also provide a “Warrant” and an “Impact”.

**Claim: **An opinion-based, falsifiable statement that supports your main idea.
**Warrant: **Factual information that supports your claim.
**Impact: **The material consequence of your Claim, in terms of your intended audience.

For example, maybe you are trying to convince your readers to stop using React Native. One of your main supporting reasons might be that it’s not _actually _native code, but still requires knowledge of native development. That’s your claim. **A **warrant would be an example of a real-life project built in React Native that did not work on both Android and iOS without additional device-specific code. The impact for your readers is on their workload and support costs, either as individuals or development teams.

Organize Your Ideas For Your Own Benefit

The good old idea web!
A Venn diagram with your preferred option & one or two alternatives
Pro/con chart
Compare/Contrast organizers

As you generate ideas, pick 2-4 ideas to focus on and develop with supporting details. Look for overlap between different reasons - like “productivity improvements” or “accessibility” that can incorporate multiple supporting examples.

A Classic Outline Template:

Problem-focused headline w/ brief mention of your preferred solution

Curiosity-inspiring opinion about a relatable problem
First reason your solution is a good one (Active verb to highlight a benefit)
- An alternative solution that didn't achieve this goal
- Why your chosen solution works better
Second reason…
- Why your solution wasn't perfect at first
- How you adapted
Third reason… (Ideal is 3-4 total paragraphs describing your choices.)
- What worked exactly as you hoped?
- Unexpected benefits you discovered
Conclusion suggesting next steps
- Current or future projects where you might apply what you learned
- Who else might want to try this approach? What kind of projects?
- Where should people go to learn more?

Sample Outline

How I Kept My OSS Project Moving With Flutter

Mobile development is hard, and so is working with people! Flutter made both easier.
Constraints are good for collaboration
- People thought Flutter would be more limiting than React Native
- The limits don't mean you'll make a worse end product
- Getting people on the same page is easier when there are clear external guidelines
Flutter Just Works
- React Native required so much "fixing", it generated tons of GitHub issues
  - Flutter takes more effort up front, but once it's done, it runs predictably everywhere
Learning Dart & Flutter is attractive to people
- A lot of devs were enthusiastic about opportunity to learn the hot new thing
- It attracted a lot of experienced people to the project who weren't that excited about more React Native
- Combo of declarative UI and OOD backend means opportunities for people with different interests
You should convert your OSS project to Flutter. Once we've built more, maybe I'll give a talk about how we did it.

3. Write Naturally! It’s YOUR Story!

Don’t sweat the details when it comes to grammar, writing style, or perfectly formatted screenshots. The most important thing you can contribute is your unique understanding of the problem space you’re working in. Write in a voice and style that are comfortable for you, and err on the side of including more technical detail than necessary - you can always pare back later.

Be A Humble Authority

Everything has tradeoffs, and everyone has blind spots. Acknowledge them! Be confident in what you know and the experiences you’ve had - but remember that confidence reveals itself in a willingness to be wrong and consider other options. Readers are far more likely to trust you and finish reading your article if they see you as an open-minded, thoughtful person than if they see you as arrogant and inflexible.

Consider a Few Tips

Most readers like casual style, concrete examples, and short sentences and paragraphs.
Active verbs and opinionated headings spur readers’ creativity and analytical thinking.
Links to high-quality background resources are great - don’t try to do it all yourself.
Plain language makes content accessible. If you need jargon and acronyms, explain!
Code samples should be formatted with markup or otherwise separated from the explanatory text - make them usable for others!

Inspire Readers With Final Thoughts

Don’t skip the conclusion! The value in sharing your experience and insights is in how it can spur learning and creativity for others. Take a few sentences to reflect on the problem, your solution, and what you learned along the way. You don’t have to be certain about any of it—it’s just fine to leave some open questions, but offer some thoughts on how you or someone else might answer those questions in the future.

4. Reflect, Share and Revise

When you’ve finished writing, don’t click ‘publish’ right away. You put a lot of effort into this - it’s worth taking a bit of extra time to polish it up a little.

Read your conclusion, then circle back to your introduction. Do they make sense together? If you provided an outline in your introduction, does it reflect what you actually wrote?

Look back over your body paragraphs. Are your code samples explained? Do your links work? Do your headings make sense?

Even if you don’t do that kind of analytical revision, sitting on your draft for a day or two gives you some time to reflect and let ideas percolate. It’s also an opportunity to share with some trusted readers. Ask a couple of other people to read your draft and provide feedback. You don’t have to change anything, but give yourself the opportunity!

5. Publish & Promote Your Heart Out

The final step, obviously, is to publish and publicize. Where is up to you, but be proud of what you’ve done and show it off – just the fact that you did it sets you apart from the crowd. You’ve shown an admirable commitment to your own growth and to your community, and we want the chance to cheer for you!

How Did You Build That? Tell A Great Technical Story

Julia Seidman — Tue, 15 Nov 2022 22:03:12 +0000

Did you create a great new tool? Solve a problem you weren’t sure could be solved? Build a demo app you want to share? People want to know about it - but unfortunately, they have very short attention spans.

This guide is intended to help you create detailed technical stories, including code snippets, architecture diagrams, etc. It might seem odd to think of detailed technical guides as “stories”, but if you want readers to follow your process, you need to have a plot with a beginning, middle and end, and you need to keep readers engaged in your narrative by making it relevant to them.

(A quick note: Have you ever read a story that seems to just be a pretext for the author to rant? Not much plot, boring characters, and lots of diatribes? Don’t be that writer! Save your ‘hot takes’ for later. This guide is for the HOW, not the WHY.)

Overview

Give your idea shape with examples and framing questions
Plot the path ahead - brainstorm and outline
Fill in the details of your unique story
Seek feedback and revise
Publish on your blog or other site

1. Define and Shape Your Idea

Get Inspired By A Few Good Examples

A few examples of “How I Built It” articles - what works for you as a reader and learner?

Start With Framing Questions

What is the problem you set out to solve? How did you uncover this problem? What were your initial feelings about tackling it?
What are the steps you took to solve this problem? Which turned out to be necessary, and which paths did you abandon?
What obstacles did you come across? Were any of them unexpected? How did you get around them? Include meaningful code snippets or diagrams so others can follow.
What did you learn from this project? What was the outcome? Are you still evaluating? Are there any next steps? What recommendations do you have for others?

2. Plan Ahead to Tell A Clearer Story

Set a Manageable Scope

A good short story has a limited setting and a focused plot! How can you bring clarity to the most important events or conflicts in your technical story?

What should readers understand when they finish? Is it your goal for them to be able to build the same project you did, or to understand the journey you went through?
- Is your goal to educate about specific technical tools? Focus on what worked.
- Is your goal to share strategies that helped in your journey? Show how you failed forward.
What background knowledge does your reader need? What do you want to explain? Provide links for other important concepts.
What aspects of the project can you explain in general terms? Leave out technical details that don’t directly affect your main “plot”.
If you need to discuss multiple levels of your tech stack in detail, what is the clearest approach?
- One layer at a time – Will you fully explain one layer at a time, with explanation of how they connect at the end? This might work best for describing a project where your backend data dictated everything else.
- All layers in parallel - Will you through the project chronologically, addressing each element at each stage? This might be a good fit for explaining the evolution of a consumer-facing app that you adjusted based on user feedback.

Organize Your Ideas For Your Own Benefit

There’s no one secret formula for outlines. A process that works for you is the winner, but it may take experimentation to find it. Try different approaches, iterate, and keep moving forward! A few ideas, taken from my days as an English teacher - in some future post, maybe I'll lay out some article ideas using these templates to show how I might use them:

The good old idea web!
An actual plot diagram - Build in a little suspense, show how conflict made the end result better.
A problem-driven organizer - The best technical stories center on a person who needs something.

A Classic Outline Template:

Problem-focused Headline w/ brief mention of solution

Subheading to introduce real-world scenario

Introduction
- What problem are you addressing?
- What are the technical requirements and business requirements that provide the context for the problem? Help readers understand your limitations & motivations.
First step in your process (Use an active verb like “Install” or “Initialize” to help readers see what their first step would be.)
- Overview of the project structure & link to important background info
- Screenshots or code snippets to show proper setup
Second step (Include a reason! “Do X to Allow Y” or “Choose A if You Need B”)
- Caveats and double-checks. Did you have any false starts?
- How will someone following this process know it’s working properly?
Third step (3-6 total steps is a good target for detail & approachability)
- Code snippet or screenshot showing important details
- Explanation of how components function together
Conclusion subheading that implies a next step
- Current or future projects where you might apply what you learned
- Who else might want to try this approach and on what type of project?
- Where should people go to learn more?

Sample Outline For Personal Python Project:

Install Python 3 to Build Quick Custom Apps For Your Life

How I Manage My Finances with Jupyter

Intro
- My conundrum: Managing my finances! My solution: 2 birds with 1 stone!
- What is Python? Used a lot for math & finance, provide some links
- Allegedly easy to learn & use
Check For Python on Your Machine
- I thought I didn’t have Python! Avoid my mistake of making a mess with 2 installs!
- Where to find the right Python for your OS - provide links & screenshots
- Include Python in Your Path - What is a ‘path’? Provide a link?
- Screenshots & CLI code snippet
Run Your First Python 3 Code Faster With Jupyter Notebook
- I assumed I’d be working in the browser! Imagine my delight!
- “Hello World!” code for Jupyter
Make The Fastest Custom Data Viz Ever
- Install a couple of tools
- Make A+ personal finance charts with C+ effort!
Build Your Next Life-Hack Project with Python 3
- Resources for learning more about Python
- Ideas for other life tasks to make easier with Python/Jupyter
- Encouraging words for new Python developers!

3. Write Naturally! It’s YOUR Story!

Consider a Few Tips

Most readers like casual style, concrete examples, and short sentences and paragraphs.
Active verbs and opinionated headings spur readers’ creativity and analytical thinking.
Links to high-quality background resources are great - don’t try to do it all yourself.
Plain language makes content accessible. If you need jargon and acronyms, explain!
Code samples should be formatted with markup or otherwise separated from the explanatory text - make them usable for others!

Inspire Readers With Final Thoughts

4. Reflect, Share and Revise

When you’ve finished writing, don’t click ‘publish’ right away. You put a lot of effort into this - it’s worth taking a bit of extra time to polish it up a little.

Read your conclusion, then circle back to your introduction. Do they make sense together?
If you provided an outline in your introduction, does it reflect what you actually wrote?
Are your code samples explained?
Do your links work?
Do your headings make sense?

Sitting on your draft for a day or two gives you some time to reflect and let ideas percolate. Even better, ask a couple of other people to read your draft and provide feedback. You don’t have to change anything, but give yourself the opportunity!

5. Publish & Promote Your Heart Out

Gratitude in Tough Times

Julia Seidman — Tue, 15 Nov 2022 20:24:33 +0000

Did you know Thanksgiving is good for your health, no matter how much gravy and pie you eat?

Ok, that may not be quite what the science shows, but bear with me! The psychological benefits of gratitude are actually well-documented. And I've been trying to embrace intuitive eating lately, so you won't hear me shaming anyone for what they eat on holidays!

There's a lot of not-great news in the tech industry of late. I live in the Seattle area, and I'm anxiously waiting to hear if anyone I know will be affected by the impending Amazon layoffs. My partner works in cybersecurity for a financial firm, and our weekend was a bit disrupted by all the FTX shenanigans. I know many people who've recently lost jobs, or who are uneasily watching as teammates are let go, wondering what's next.

It can be hard to feel grateful in times like this. But gratitude is powerful medicine, and we could probably all use some of that right now. I'm a perennial career-changer, and I do have some impulse to flee for other industries when things go south - the day I decided to leave finance for good was when Bernie Madoff was arrested, and my last day in the office was the day he plead guilty. But I've matured, and I think maybe it's a good time to take stock of why I truly am grateful to be in the tech industry now.

There is a place for everyone here. I'm continually amazed and delighted by the incredible range of companies, jobs, and people at work in the tech industry. It may take a while, but if you're looking for your place, I'm confident you can find it.
People care about making the industry better. We still have a lot of progress to make on inclusion and diversity in tech, but in general, the tech industry is doing a lot better than a lot of traditional white collar professions. I started my career in high finance, and I am SO grateful to now be working in a place where I see and feel genuine investment in making tomorrow better.
Weirdness is welcome. For a person who chafes against authority and instinctively shudders at requests for conformity, my first and second careers (in finance and public education) were not great fits. I'm very happy to have discovered a career where, if anything, I'm the boring one! I love working with people who are excited to share their unique passions and perspectives, and not afraid to let their quirks show.
I never get bored. Sometimes I think I'd be happy to have a chance to just sit still with one thing for a while, so I could gain some feeling of mastery with something...but if I had to pick one extreme, I'd definitely choose the side of constant challenge and change. I'm pretty easily bored, and I love knowing that my career will always reward me for learning more.
I meet amazing people. You know who's awesome? You! I find so much inspiration from people throughout this industry. I don't mean that every single person I've met has been my favorite person - I've definitely had some job interviews where I thought "Well, I'm glad I won't be working here." But in general, I've found people are generous with their time and knowledge, and are really happy to support other people when they can.

I'm sure I could come up with more reasons, and maybe I'll do a follow-up post with some more. How about you? What are you grateful for? What can you do to find some gratitude, even when things are looking kind of bleak?

Developers Should Write Because...

Julia Seidman — Thu, 10 Nov 2022 22:17:29 +0000

When I went to graduate school for Education, we often came back to the concept of "Writing To Learn". Writing has always come very naturally for me, which I recognize isn't true for everyone. In my job now, writing is my product - I learn about a new technical product or concept so that I can write about it. My writing serves to educate others - but it's also been the most effective way I've found to learn and grow as a developer. When I write, I learn.

Write Because You Want To Learn

You don't have to love writing or be a "great" writer to benefit from it. Truthfully, I don't always love it myself! The point of "Writing to Learn" is the cognitive processes that happen while you are writing. It's not about the product, and it's not really about the aesthetic enjoyment of the process (though I think even a lot of reluctant writers can find those benefits with practice). Because we're not concerned with the end product, nor held to any particular standards, this model of writing is actually pretty liberating!

The main value we're trying to realize with a "Writing to Learn" approach is personal growth. When you write about a subject, your brain is engaged in a much more complex cognitive process than when you simply read. Writing promotes memory formation and often allows the writer to build more complex mental models than with reading. It provides opportunities for reflection and analysis, allowing you to challenge your initial assumptions and engage in deeper systems thinking.

All of this is probably not news to you. It's pretty standard 'teacher talk', although I think it's still good to remember. Think of this as encouragement to write purely for your own benefit - whether you ever publish anything, and regardless of how many 'likes' it gets, so long as you're writing, you're doing something that's intrinsically valuable.

Write So You Can See Yourself Grow

I get another benefit from writing about development that I didn't anticipate when I started. In fact, I didn't even notice it for the first year or so of my career as a developer-writer. For me, writing is an important tool in combatting impostor syndrome.

I could go on at some length about my mixed feelings on impostor syndrome. I think it's an easy out for dealing with some much more deep-seated issues in the industry - but that's not really why we're here today.

Really, the point is, sometimes we all doubt ourselves. We work in an industry that never stops changing. Careers in tech never feel completely comfortable, because we are all constantly working right at the edge of our abilities. As our skills progress, so does the complexity of the work we do. It can be exhausting. You will spend the same amount of time in frustration after three years or thirteen years that you did when you had been doing this for three months. It's easy to feel like you are hardly moving forward.

But if you write as you learn, you can look back and see the record of your progress. On days when all I can remember is the desperate feelings, self-doubt, and flailing, taking a look at something I wrote two years ago helps me get some perspective. As I step back, I get perspective and see that, really, I've come a long way. It works at the small scale, too. Even if I don't manage to write a single line of functioning code today, if I write down my thoughts about what didn't work, I'll be a step ahead when I start in again tomorrow. And if I manage to write an article that actually helps someone else, I feel like a hero, at least for a little while! I may still be flailing, but I'm out of the kiddie pool and into the lake. So long as I keep my head above water, I figure eventually I'll make it down the river and into the bay.

Write Because It Doesn't Have To Be Perfect

So, where to start writing? It really doesn't matter.

If you're writing thoughts down on sticky notes, make a habit of going through those notes every Friday and writing up a narrative of your week. Send it to yourself in an email if you don't want to share it.

If you're researching a new framework or library, or learning about a new design pattern, open up your Notes app and copy/paste in links from everything you read that helps you. Add a couple of notes explaining what you learned from each source. Once you think you've got a grasp on the concept, write a paragraph or two to explain it. Come back the next day and turn it into a blog post if you want - or don't! You'll still have gotten a lot of value out of the practice of organizing your thoughts and reflecting on how you learned.

I'm going to try to take my own advice and do a little more writing here over the next few weeks. Sometimes, the amount of writing I do for work can leave me without much energy to do more! But I know how valuable it is. I practice for progress, not perfection, so I'm going to try hard not to worry about everything here being 'professional' quality. As I said earlier, "Writing to Learn" is meant to be freeing - the end goal is just to keep moving forward.

Why Documentation is Essential To Your DEI Initiatives

Julia Seidman — Thu, 23 Sep 2021 19:43:22 +0000

The last few years have seen a remarkable - and much-needed - increase in attention to diversity, equity, and inclusion (DEI) across the tech industry. It would be hard to find a serious player in SaaS, DevOps, or developer tools that doesn't have some kind of DEI mission statement, and most of the people I work with seem earnest in their desire to make changes for the better.

Change is hard, though. It's harder still when you only talk about problems in the abstract. What's often missing from the conversation about DEI is an actionable roadmap for improvement. I get it - it's hard to know where to start, and it's scary to acknowledge where we're coming up short of our values.

That's why I think better documentation is a powerful step in the right direction. It's often developers' first interaction with your company or your community, and ensuring that you are welcoming all kinds of people is essential if we're going to achieve those DEI goals.

How many of us, at some point in our careers in this industry, have found ourselves held back in some way by developer content that didn't meet our needs? We could talk all day about bad advice on crowd-sourced platforms, but even major companies often fill their developer portals with poorly organized, dense documentation that assumes a lot of prior knowledge. Finding the content you need in a form you can quickly grasp can be a time-consuming challenge, even for experienced developers.

The struggle is even more significant for people coming from non-traditional backgrounds. Much of the diversity in the developer community is not coming from college computer science departments. Self-taught developers and bootcamp grads are more diverse in many ways. They often come in with substantial practical skills, but without much grounding in computer science concepts, network architecture, or the history of technology. They also may not have the same 'insider' knowledge of names, events, and memes that industry veterans take for granted.

Documentation that assumes all developers come with the same background is exclusionary -- and there is a lot of it. If we want an industry where developers from all backgrounds feel welcome and supported, we need developer content that meets people where they are.

I'll be approaching this topic from a few different angles in the coming weeks. By no means is fresh developer content a substitute for the difficult, more complex conversations we need to have about DEI. Problems run deep, and solutions are going to require a lot of hard work. My hope is, though, that by showing one simple path towards improvement, I can help you create progress in your organization.