Forem: ladyofcode

Factors to consider in choosing a tech stack for a project

ladyofcode — Tue, 30 Jul 2024 02:06:48 +0000

In the middle of writing a rant and a half (thanks, Twitch chat), I ended up with a list. That list kept growing, so it's now its own article instead.

Below is a non-exhaustive list of things I consider when picking a tech stack for a project. The weighting of all of these differs between projects. What I'm looking for is:

How flexible is the stack?
Where does customisation to the project happen?
How will the piece of tech affect the wider workflow and pipeline it's a part of?

The list

Team presence

Teams are a double-edged sword; sometimes decisions are made for us, and at other times are a minefield of opinions. Often we'll need to take everyone else's (everyone relevant 🫥) strengths and views into consideration.

Performance

Why does it perform well?
Where are the bottlenecks?
How does it perform at scale (not just for a li'l starter repo)?
How is the tech managed at scale?
How does this piece of tech compare to other similar pieces of tech?

Benchmarks

There are many different benchmarks. You'll have to look and consider the relevant ones for your use cases.

How are the tests performed?
Are the tests standardised, and appropriate?
Are they updated?

Security

Are there any massive vulnerabilities?
Are there special features to address security concerns?

Developer experience

Is this a test of spiritual endurance, or will I be mentally frolicking through a meadow?
Are there features I appreciate?

People have varying opinions on these — just take a look at the CLI- vs GUI-based crowds. If you prefer GUI tools just be prepared for someone, somewhere, who won't take you seriously as a developer.

Replaceability (of me!)

Aside from being convenient for my employers, what about me (yes I am definitely making everything about me here)?

Should I want to leave, will my employers find a replacement quickly?

Side note: There's no need to fabricate a situation where one can't be fired by using more complicated tech. Do good work, be a good employee, and they won't want to fire you. It's not like you work in DevRel.

Maintenance

How difficult is it to maintain a project once it's 'completed' by me or others?

(We know projects never get finished - they're either maintained or confined to the depths of Davy Jone's Repo).

Compatibility/integration

How compatible is the tech with any existing tech or tooling?
How does the tech integrate with other tech we're looking at in the stack (especially for testing)?
How seamless is the integration process?

Ecosystem and support

In my case, if I'm picking a new technology, I'll need either solid documentation or a community to badger if the documentation is sub-par, which is often the case.

How strong is the community surrounding the tech?
How responsive are they?
How many plugins/tools have been made available for development?
How easily readable are the docs?

Speed of building

Believe it or not, not everything has to be built ASAP. There are tradeoffs for everything - if there's time to learn tech to use the right tool for the job, that is preferable.

Does this need to be really quick?
If so, is the level of familiarity important?
Is generating income quickly (or a deadline) from the product factoring into my decisions?
If there's the added difficulty of adding certain features without any existing plugins or libraries to make it quicker, how will that affect the time to implement?
How steep is the learning curve?
Will I need to purchase training?

Cost

What costs and resources will be affected when it comes to building?

Future-Proofing

Using outdated tech can hurt projects.

Is this technology 'future-proof'?
How frequently is the tech being updated i.e., will it become obsolete soon, especially at risk of security updates or clashing as a dependency?

Vendor Lock-In

Not always a bad thing... But usually not preferable.

Is there a risk of vendor lock-in?
How easy is it to switch to a different technology if needed?

Compliance/regulations

Who knew laws are a thing?

Are there any compliance and regulatory requirements to consider?
Does the technology meet industry standards and regulations?

Whew!

That was long. Congrats and condolences on making it this far. What else do you look for?

Perhaps I should make this into a checklist as a part of a website funnel, eh? "20 things to look for when you start a project - just enter your email below". Too bad I don't care.

Good luck with your projects!

How being a designer reduced my pedantry in arguments and affected my language

ladyofcode — Mon, 19 Feb 2024 19:45:41 +0000

Design has impacted how I handle myself in various situations across all spheres of my life - personal, professional, social, and everything in between. More specifically - trying to become better at design has led me to practice a certain subset of skills involving empathy and related characteristics.

I try to do things to the best of my ability. When I first started learning about design as a discipline beyond the confines of graphic design, which was my first introduction, I settled on a notion of design consisting of two things: how well we understand people, and how well a solution could be creatively tailored to that understanding. I focus on the former in this article; that's where this all started: the psychology of people.

It could be said this was a likely effect of my journey into adulthood. I venture that this maturation meant I was more receptive to what I could understand and the depth of what I was able to learn and subsequently apply. These changes also started fairly early in my twenties and well before my current capabilities. At this stage of my life (thirties, o no), the jar of fucks I have to give about most energy-draining things is slowly emptying and being replaced with cookies, which are far tastier.

Conflict resolution

One of the areas heavily impacted by design is the way I handle arguments. This was most easily seen in text. The level of pedantry to counter every single point was excruciating; more so if I was engage in an argument with someone with the same behaviour.

At some point I subconsciously decided that being right wasn't worth it. Arguments are unavoidable; ugliness isn't worth the effort. Leaving my ego at the door was nigh painful; becoming outcome-focussed meant resisting the urge to comment on everything and instead focus on resolving the conflict.

At this point in my self-development journey, I no longer feel wronged in a similar manner. How people behave is a reflection of themselves, and not necessarily myself; who am I to take their feelings personally? Those are theirs, and they're usually valid. Most people I engage with (luckily!) aren't unreasonable, and feelings on both sides can be valid even if they're contradictory - which leads me to my next point:

Both can be true

There is a lot of black-and-white when it comes to people being steadfast in their emotional standpoints when the reality is we're swimming in a grey area. I find a lot of my responses these days have become 'both can be true'. Someone could feel hurt at something seemingly innocuous I said that wasn't intended to do so; I don't have to feel like I did anything wrong (depending on what it is), but I can still apologise for having that effect. Someone hurting, or being right (perhaps with a hint of superiority or smugness, hm? Yes, the irony was intentional 😆) - what's more important? Most people aren't careful with language in they're communicating.

Another design epithet that hit home: focus on what people mean, not what they say. Imagine the agency I felt when I discovered active listening skills.

Character development

Early on I came to the conclusion people are the eventually the receivers of most things we do - be it ourselves or someone else. Even when we do things for altruistic purposes, we usually benefit internally to some degree. Being kind makes us feel good. While I became more kind and enjoy helping people, I became selective to whom I gave my energy and no longer tolerated toxicity.

Note that this doesn't mean one must tip-toe around the feelings of others all the time. In reading the situation 'correctly' we're able to make more appropriate decisions; personally, I'd rather someone found me to be an asshat only when I intended to be one (and yes, I do this, albeit rarely!).

Changes in communication

Being empathetic and outcome-focussed in more difficult conversations has required changes in communication both verbally and in text:

Language: The nature of the language I use is more tactful than it used to be. I've always been straightforward in communicating issues, but not necessarily as careful with my language.
Efficiency: I hesitate to call myself articulate, as I could be more concise and efficient, so I often describe myself as wordy or talkative (oh, the irony). I would like to think I've become better at being concise when the situation warrants it.
Reception: Fewer text walls in social messaging apps or emails. Whatever is being communicated often gets amplified and tinged with overwhelm, which is not something I would like received. Calls are better.

My use of an obscene number of emotes and emojis has remained, however. They're a fantastic indicator of tone, which can be difficult to glean through text. I'm never gonna give them up.

Hehe. :3

There can be downsides

There's a lot I've learnt about handling people. Ultimately, much about becoming a better designer was tightly coupled with becoming a better person. Empathy overload combined with kindness can contribute to deteriorating mental health. If someone were to go down this route of self-development with empathy there needs to be growth of self-awareness and emotional regulation. Boundaries need to be slammed down when appropriate, and protected. I may have a long way to go, but the learning process has been invaluable in many facets of my life already.

In conclusion

In giving advice to developers, I encourage them to learn about design: at minimum learn to have more empathy for users, if nothing else - though there's plenty on designing effective systems and solutions that is relevant to a developer, especially if you work in small teams or alone. I advise designers to learn some code too; many who take their work seriously do it because they value that understanding.

Be a paradigm-agnostic developer

ladyofcode — Sun, 11 Feb 2024 20:22:39 +0000

Programming paradigms dictate the way programs are implemented - conceptually, they give them a specific structure, style, and characteristics. I use 'paradigm-agnostic' to mean someone who doesn't constantly advocate specifically in favour of one programming paradigm.

Do you need to be paradigm-agnostic?

No.

Plenty of developers make a great living having learnt one language, and perhaps a relevant framework, as well.

So should you?

That depends on the kind of work you want to do, how far you're taking your career, and, by extension, the kind of developer you want to be. I'd answer 'yes' for any of the following:

Architecting systems
Detecting anti-patterns
Becoming a highly-experienced 'senior developer'
Reaching the mythological mythological unicorn developer of legend
In rarer instances, when your favourite not-favourite language decides to migrate or include features from another (guess who had it easier when JS and React started leaning into the functional paradigm, ahem 👀)

Admittedly, these things are all related; I'd file them under 'being a great software engineer'.

During an interview for which I was approached once upon a time, the interviewers (both tech people - the founder and CTO) specified that while solid React developers were aplenty and easy to come by (ouch), they wanted someone with strong programming skills: someone who could spot anti-patterns and be responsible for the health of their codebase. 'Someone who can actually program'. That stuck with me.

If you're going to be doing actual software engineering, and not simply coding, that suggests you're moving across numerous projects with different languages, tooling, and architecture. To navigate them well - or, further to that - pick and use the right languages and tools for the project, being able to understand their applicability is important. Being able to use a variety makes you more employable as well as benefiting projects, too; a business may be less inclined to feel limited by their developers' language knowledge.

Truly experienced developers will often have a personal preference, and that's fine - but they won't use this as a reason to pick something for a project, like children over Pokémon vs Digimon (did you just pick one internally? 😆). I know the line height isn't especially large, but you should be able to read between them and hide that sort of paradismal behaviour if you ever feel inclined towards it.

How to get there

Learn different languages with different paradigms, if that wasn't obvious. I'm sure it was. But do so with intention:

One of the best things you can do is reinvent the wheel in different paradigms, across multiple languages (e.g. manipulating arrays) and understand how they work under the hood. This will help build the mental model for each paradigm. The more you work with them the easier it'll get.
Understand how algorithms and data structures are implemented within different paradigms.
Learn best practices for various languages and tooling. You don't have to memorise them all; it's more about doing things well. Patterns will reveal themselves and those will stick.
Actual understanding is important. Doing a course quickly with a couple of cookie-cutter projects isn't necessarily going to consolidate that understanding internally. Be thorough.

I only realised how useful this was after I had done this for years, courtesy of my degree, and it's something I recommend others to look for in their education. This was out of sheer luck; it's difficult to be intentional about picking a degree as a noob.

If that's something you decide to do, good luck - and don't forget to make learning enjoyable!

Things you should know before learning Three.js

ladyofcode — Sun, 04 Feb 2024 19:36:59 +0000

For one of my 100-Day Challenges, I chose to dive into Three.js, a JavaScript 3D library. It's easy to start learning, and it becomes difficult to master with the inclusion of shaders.

If you're too lazy to click that and don't know, it leverages WebGL . For the portion of readers who are consistently and ignorantly (fair, we all do it) in character:

WebGL is OpenGL wrapped up for the web.
OpenGL is an API for rendering 2D and 3D vector graphics.
Vector graphics are defined by equations (like SVG - Scalable Vector Graphics) instead of storing data for each pixel (like JPEGs!)

Those are important to acknowledge. Three.js requires an understanding of multiple things to make decent headway:

Foundations of programming
Solid vanilla JavaScript skills, along with HTML and CSS
Understanding of the DOM - how to access elements and manipulate them
3D modelling skills; building models, lighting, structuring scenes, and so on
Art! Understanding colour, perception, and so on to make something appealing

Three.js is a library sitting staunchly in that intersection of tech and art.

That's not to say someone couldn't get started without those. These skills have to be developed anyway to create beautiful pieces of work - either before starting Three.js or along the way. Personally, I wouldn't recommend learning Three.js to someone who just started learning how to code, but I wouldn't stop them if they had the determination either. I could just imagine their developer training montage set to Eye of the Tiger, burning their retinas instead of the midnight oil. Developers may be masochists but individuals who persevere through Three.js (or WebGL, or OpenGL - or to be honest, any graphics coding) early into their programming foray are next-level. 💀

3D modelling

Three.js is particularly intertwined with skill in 3D modelling; the best experiences feel like a brilliant combination of art and technology. It's best to start with Blender early - it's forever free, and open source. Autodesk's Maya is also freely available for students with an academic email address; I'd recommend it for someone who wants employment at places that consider Maya the industry standard - a contentious topic if Xwitter is anything to go by!

Shaders

Shaders, the little programs that manipulate images before they're rendered, are where mastery lies. Shader programming can be a bitch and relies heavily on maths and understanding textures. Have a look at Shadertoy to see what people accomplish without much on the 3D model front.

I found myself needing to go back and refresh my maths to understand some of the programming involved. This process can be complex and take quite some time; I had to return to maths at the pre-calculus level and take it from there because the kind of work I do requires none of that whatsoever. If matrices, vectors, geometry, and the like aren't things you're intrinsically motivated to understand, you'll cap out at which level you can use Three.js.

Tips for your learning journey

If you're not going to do a solid course on Three.js, I suggest having a look at their syllabi, ensuring you learn about the topics listed. Do a 3D course of some kind if you have no familiarity with 3D modelling at all. Watching people build models is also useful once you have some understanding of the software; live and recorded videos have different advantages so give them both a shot.

Make a pathway based on what you lack. I wouldn't recommend trying to get all the maths sorted early on, unless you're motivated to do exactly that. You could make Agile finally useful for something and cycle around 3D, art, programming, and maths as you manoeuvre the output into increased complexity as your capabilities expand.

It'll take time, but make sure you're enjoying the process. I still lurk in the recesses of Three.js noobdom and have to revisit various topics every so often in between my other projects and obligations, but the continued enjoyment makes the long journey worth it.

glhf 💖

How to get clients as a freelancer

ladyofcode — Sun, 28 Jan 2024 18:51:14 +0000

I'd like to make one thing clear before we approach The List:

Behave like a professional before you start advertising.

Make a free website, buy a domain, make your profiles, set up the relevant socials, and put some examples of your work out there so people can see what they're signing up for. People will ask for this to verify your work, and to refer you. If you can't verifiably demonstrate what you're capable of, it'll be much harder to gain the trust of someone to pay you to do work for them. At least look like a professional starting out and demonstrate you are capable of effort particularly if a beginner's skillset is being advertised.

Okay? Okay. Let us begin:

Do volunteer work

This one is for the nooblancers struggling to get pieces into their portfolios. Do a project for a family member, or a local religious institution, or an underfunded organisation/cause you find meaningful. Having something in use is better than nothing, and you can potentially generate leads from that, too.

Lower your rates

Another one for the super nublet nooblancers. It's okay to take a pay cut temporarily while you get your network going, especially if you're still learning, like many students are. Just ensure that you are being clear with your clients about this discounted rate (in case they refer you or want additional work done). After I moved countries I cut my rate (my student rate!) for some time until I built up experience, clientele, and the gall to say no to projects I didn't to do and people with whom I didn't want to work.

Tell everyone

Tell yo' kids, tell yo' wife, tell yo' husband. Everyone should know - your family, friends, and friends of friends. They may refer you if something comes up - to other professionals, if not to potential clients. Your existing network should know.

Cold calling and emailing

Cold emailing sometimes works, but be sure to personalise them and make them specific; tailor your emails to the business you're emailing. Canned templates are easy to spot and usually get deleted instantly as spam.

A step up would be to pick up the phone and call to deliver your pitch.

A bigger step up? Knock on doors and show up at businesses physically. If you're armed with an understanding of their business needs and highlight it to them, your time and effort may be appreciated enough to get clients.

Networking

This is likely going to be where you find your best clients, whether they're your first ones or not. Personally, once I found great clients, their referrals brought me other great clients; they were referred to me because the IT department at my university knew me as someone who did custom design and development work outside of my day job.

Relationships need to be built with people. Establish trust and provide value before you ask them for things. This applies to both online and offline. Here are some types of relationships to build:

Twitter/X, Instagram, LinkedIn, and other social media sites are underrated for getting projects. You don't need a popular account to share your work and network well; plenty of people get offered work in DMs after building these relationships with people representing businesses or themselves as professionals.
Join local groups in your niche to network with other freelancers around your industry.
Start a community of your own with a specific purpose. I'd learnt this when I'd started a community of my own to have fun with tech, but as our reputation grew, so did work requests. Facebook groups are a good example of this and may have communities that operate offline as well.
Network with other professionals at local meetups.
Agencies often hire and contract out work, so you could let them know you're available for work. It would be better to develop relationships with them first.
Join a co-working space.

Post on your local classifieds

-especially if it's free. Post in newspapers if necessary, but online classifieds sites work as well. For me this was Gumtree - I included snippets of my university projects and other paid work in my ad and got responses.

Side note: people offered items or services in exchange for my services. Bartering is underrated.

Freelancing websites

This is here because it should be a part of the list. It is competitive on the most popular platforms and high effort, but not impossible. While I wouldn't dismiss them, I would make this a later-priority item unless there is a local website in which to stand out. It takes effort to bid and handle your rates, but it's definitely doable and beginners have had some success.

Special note for web devs and designers

It's easy to start with WordPress sites and similar, popular CMSes, and in particular themes that use page builders. Over 40% of websites are built with WordPress, and it's a better tool to pitch to small businesses who want to create and manage their content with a more user-friendly experience than other open-source tools available. These sites are not the most performant, but they don't need to be for small projects.

A personal opinion here: I prioritise the user experience of my clients over upselling software that would force them to hire someone for small changes, particularly constantly. I pick popular tools and software that are appropriate for my clients' projects; being replaceable is a good thing - the value I bring to the table isn't simply the ability to code. My clients refer me and return with new project requests as a result, and because they have the confidence I'll do right by them and their projects. This is a better reputation to build as a part of your brand.

Lastly...

I have to make another point now as I made my final point at the beginning of this article, so here: have a contract ready to sign. You can prepare one from a free template in the meantime while you start generating leads for yourself. Do yourself that favour: be prepared to actually take on work. Good luck!

'Which programming language should I learn first?'

ladyofcode — Fri, 19 Jan 2024 19:13:55 +0000

Spoiler alert: it's not automatically JavaScript

We have on our hands another contentious topic (at least according to Tech Twitter/X): recommending a language to learn. People are often so unfoundedly opinionated on which language to recommend to coders and staunchly back specific languages much like the fanboying behind PS2 vs. Xbox of yesteryear (yes, emo millennial present 🙋🏽‍♀️). Why aren't we recommending languages the way we'd pick them for projects - or do you just pick your 'favourite' language and roll with it regardless of whether it's appropriate or not for every project?

I've encountered a variety of opinions on the web:

Why do people even bother recommending C or C++
Learn JavaScript or Python; it's more beginner-friendly
Everyone should recommend JavaScript because the barrier to entry is easier

and far too many other, equally grating statements.

I find the advice varies more with developers who are paradigm-agnostic and can code in a variety of languages; y'know, the kind of expert who has their preferences but doesn't behave like their favourite fandom ship sailing around the very core of their identity is being attacked.

The List

The following scenarios I give are not exhaustive. Here are some languages and stacks I've recommended based on people's situations:

'I need to freelance ASAP [with a future in web]'

WordPress, HTML+CSS, and PHP if they can't afford to be selective about clients. Any popular CMS stack works - see what's common in their local area. Copy and paste JavaScript to start with. Use a site builder they must. Doing work for small businesses is an easy way to get started, build a portfolio, and then raise rates. See also: Shopify and Liquid.

Some agencies just want basic templating skills from a beginner because they do work for smaller businesses or departments. Though few, there are roles that exist requiring just HTML and CSS with minimal JavaScript. UI design skills would likely be more beneficial here than advanced programming skills.

'I want to learn enough to get a web dev job'

Pick a popular backend/frontend language and/or framework that jobs popularly request in their local area and start building projects. Companies with a good culture want to invest in their employees and products; they will train them to have good habits. Companies with crappy cultures may not train new employees, or may encourage hacking (the quick-fix kind that breaks things down the line), so be wary. Agencies and companies might want different stacks; have a look.

The same applies to remote work, but it'll be more difficult to land a junior role without a solid portfolio, particularly without networking.

'I want to program well'

C (procedural), followed by object-oriented (perhaps some Objective C =/C++, then Java/C#), then Haskell/equivalent (for functional programming). You'll cover a lot of paradigms, system knowledge, and hone habits you don't even know you'll benefit from until later. Throw in a logic programming language like PROLOG, or assembly (MIPS, anyone?) for additional pain. Algorithms and data structures are good to study. They're prepared for this undergrad level of effort. They'll probably find it easier to pick up other languages after they've willingly spent time tearing their hair out. If my hair were thinning I'd have a valid excuse.

'I want to work for govt or large institutional organisations'

Look at the job ads for positions in those departments, and the tech they use in their deliverables. Start with those languages. I can tell you straight off that in my area I know the government uses Java, Spring, .NET, and Angular. SharePoint too. Agencies tend to use Drupal for government department projects. It'll be different in other locales and countries.

'I want to analyse my data'

Python, R, etc. Usually, academics or students are asking me this, and they're doing mostly light work: copying and pasting with a bit of editing. Whatever is most suited to the data they need to process should be the language and tool suite. Sometimes they might just need enough to use a Jupyter notebook and be done with it.

'I just feel I should know some code'

Tell code to piss off. If one must, learn problem-solving and planning skills because that is at least transferrable. Most people likely will not be set back by not knowing how to program in their lifetime. Sorry, Gen Alpha <3

Juggling priorities

So to even get to the above, in choosing a language one should consider:

What is being created and why
The ultimate purpose of the projects
The nature of the projects
The intentions for the deliverable (some people only want to learn to code to bootstrap apps they can then use to generate income and do something else, and that's fine)
The job market
Whether the need for income is dire
The intentions of the coder for themselves (not everyone cares about being an expert or becoming a senior developer)
The level of tutorials and documentation available (newer languages often have far less support, especially at the beginner level)

In summary

Recommending a language or tool is subjective. It always should be. We spend time debating and considering stacks for every new project we undertake - why should someone seeking advice not benefit from an iota of that deliberation? If someone is already choosing a solution without understanding personal, user, and project needs, perhaps consider what that says about their attitude towards problem-solving.

Coming up with good personal projects - Part 2: Planning and scoping

ladyofcode — Mon, 15 Jan 2024 16:41:18 +0000

The key to successful, finished projects

It was a dark and stormy night... Not that you noticed, seeing as you were probably holed up in your home, alone, buying a domain name for your next big idea before it has even materialised. Key point: alone, as in working solo, and not as in a B-rated horror film with a jump scare around the corner.

To get from that domain name, or idea, to an actual project deliverable, you will require:

A plan; however rough
Grit; to execute said plan

These are, of course, variable.

We're also assuming you have the resources to execute said plan. If not, tough cookies.

A few things to note

'~~Art~~ Software is never finished, only abandoned', as the adage from Leonardo Da Vinci doesn't go.

'Finished' or 'complete' anywhere in this post refers to software being in an 'acceptably complete' state. That could be a minimum viable product, or it could be every feature that's on the list - the state will be determined by your criteria.

If you haven't planned a project before, know there is a high likelihood of getting things way off the mark. You may readjust projects quite a bit after working through them. You'll get better at it the more projects you undertake; such is the benefit of developing experience and expertise. Just don't forget to multiply the total time you think it takes by Pi (multiPi? 😇); I jest, but mildly - that is, in fact, a common attitude for better time estimation.

It's easier to think in terms of larger milestones first. You may find milestones shifting the more you break them into tasks while you scope and figure out where the complexity lies.

Lastly, time tracking may be useful for you. Outside of this personal context, it is appropriate to react with abhorrence and distaste, as though you accidentally put soap on your toothbrush instead of toothpaste. Many supervisor-types use it as a way to micromanage or evaluate performance. Never encourage that.

A notier note: leave your comfort zone

If you're learning something new at any level, you're likely using tutorials, documentation, and other informative resources.

Tutorial hell isn't the best place in which to get stuck. People end up doing projects other people have already built forever and that's... Not really anything new. We also stay inside our comfort zone. A few ways to get around this are:

Do projects you find easier and then add features to them.
Take more complex projects and break them down into smaller, more manageable tasks.
Make sure you have ways to get help if you're out of your depth. Learning in a community is usually better for this.
Add a deadline. A real, tangible deadline, that feels hefty.

The underlying point of a tutorial is to teach you something; not give you a portfolio deliverable. Much like how great artists make a song their own when creating a cover version, you should make projects yours.

How planning changes across different types of projects

Obviously, smaller projects should require less planning. There are different ways to plan, and honestly, you don't really want scope creep happening to your planning. Most work should be done on the actual deliverable. ;)

Smallest projects: you probably have an idea of how this should pan out without much written planning, and you'll mainly want to be aware of creeping feature lists.

Larger projects: these take much longer. Duh. 🤣 As personal projects grow to become larger, they tend to require either expertise or more time dedicated towards learning in lieu of the former.

Will the project stay just yours?
How is the workload getting managed?
What do you need to learn to produce the deliverable?
What resources would you need?
If important, how will you avoid scope creep?
Is there a deadline, for some reason?

Personal side projects, of course, come in variable sizes. The great thing about ownership of the project being yours is you can adjust as you go.

Things will change as you learn new information; embrace this attitude early and adapt your plans as you go. It's okay.

Tailor the project to your needs

Use shortcuts to help you create the final product you want:

Libraries
Frameworks
Programs and services
Ask experts for advice!

The idea is to not build everything yourself, especially for large projects. Sometimes the point of a personal project is to build it yourself (for your understanding, or whatever), so if that's the point... Have at it!

I have a piece of off-the-cuff advice:

Don't use best practices (sometimes!). I know how that sounds - but sometimes, for practice purposes, you're better off having a working project than not much of a project at all.

A half-baked project will get you further towards your goals than none at all. The preferable solution would be to take a shortcut and use a solution that's already implemented best practices, even if you don't understand them (particularly if there are going to be any security loopholes). Context matters, though; for example, we don't store passwords in plaintext or send them in emails. I hate to say it, but companies exist that do this.

Bend to the brain

Don't forget to account for a realistic cadence when it comes to working on the project. What time do you actually have available every week to work on the project? After full-time work, family obligations, socialising, sleep, commutes, and everything in-between - what's left that's going to be spent on the project?

Our brains are wired differently, and psychology that works for one person may not be suitable for another. Do you need to be able to visualise progress? Can you follow a schedule well ahead of a deadline? If not, how do you need to manage yourself to get there? What do you actually need to get your work done? If something has stopped you in the past, what can you change this time around to help mitigate that?

If you haven't figured out a system that works for you yet, bear in mind this adds to your cognitive load. Please don't feel guilty if you haven't figured out your own brain yet. It can - disappointingly - take years of trial and error. But hey, real self-development is a lifelong endeavour.

There are many questions you could ask yourself; the idea is to cultivate the system by which you operate, instead of just the project, as if it exists in its own void.

Get the project acceptably finished

Yes, yes, we know the old adage - a project is never finished. At best, it enters maintenance mode. Personal projects are regularly 'unfinished', and if this is something you intend to use as a portfolio piece, and the code is public, it's best to leave it in an acceptable state even if archived.

You can choose some qualifiers ahead of time for different versions of the project. What would be the minimum qualifiers to release it, to consider it done, or usable? What's beyond the minimum, and how necessary are they? They don't have to be necessary; you should just be intentional with your choices and have reasons.

Reasons projects fail and how to avoid them

There are a multitude of reasons projects fail, and they're often due to a combination of reasons under the umbrella of terrible project scoping. When it comes to personal projects, you know yourself best (condolences if you don't), so of course you'd need to learn and adjust accordingly. It'll be more difficult to avoid them in the beginning; you can, however, become someone who halts patterns early. That self-awareness will do you better in the long run.

Some reasons for failure:

Unrealistic expectations
Not breaking down larger milestones into tasks with enough granularity
Poor time estimation
Poor personal time management
Resources run out
Choice of tools and software (How familiar are they to you? Are resources plentiful?
Scope creep
Poor communication
Poor health management

Some of these are difficult to avoid without experience. Research and advice will be important for better planning, especially for larger projects. And, more importantly, leave space for things you won't have accounted for, whether that be time, money, effort, or something else. Plan for your worst days, not your best, and you'll probably have better expectations in the long run.

The consequences of these variables failing affect your ability to perform - as a human, not just as a creator. Your physical, mental, and emotional energy will be affected. If that happens (for most newbies, when), prioritise your health first. Fatigue is easier to handle than burnout, so slow down early. You can always return if you want to.

How to scope

Scoping your project out is easy:

Step 1: What do you want?
Step 2: When do you want it by?
Step 3: ???
Step 4: Profit

Okay, so while I jest - again - there is some truth to it. Scoping is about defining what will be done, and how:

Define your goals and objectives

What are you doing? Why are you doing it? Goals are the higher-level achievable outcomes. Objectives are measurable and intended to help towards a goal.

A clearly defined audience is important, even if that audience is just yourself.

Define the project's deliverables

What are the important features and capabilities? What are the goals going to achieve?

List out requirements

Requirements may involve resources or timelines. A series of deadlines, for example. Requirements can come from any part of the project - you could have a design requirement. Minimum launch criteria are good to consider here. Termination criteria are also good to consider here; what's required to have met the project's purpose?

Axing criteria is also important - what would be required to end the project prematurely?

List constraints and exclusions

What are you going to not do? If there are reasons for this, even better.

Break down the deliverables into milestones

...Then break down the milestones into tasks. Keep doing this until you understand the different parts of the project and it looks feasible. Tasks should be actionable and clearly defined.

Create a roadmap

Timelines aren't as important for personal projects are juggling multiple personal projects, working better with deadlines, or other specific requirements that involve reasons for deadlines. Finishing a few projects is preferred to many unfinished projects.

If you aren't pressured, deadlines are less important and you can constantly work on the project until you're happy to consider it finished. At the minimum, order your tasks so you have a roadmap; add your time constraints as required.

Organising your projects

Tools!

Trello
ClickUp
Basecamp
Asana
Google
Microsoft Projects
Whiteboard with Post-it notes
Paper

If you're working alone, it'd be more effort to adopt a project management methodology than to simply undertake the project. Personally, I would just spin up a board in Trello or ClickUp Kanban-style; if it's a small project, I keep a to-do list inside my project repository instead. Most of the software's extra features are unnecessary for personal projects - you basically just need to be able to construct a roadmap of some sort.

Good luck!

That's it!

Good luck with your project. As always, I'm happy to hear about it, so feel free to share them during my streams on Twitch!

Thanks

Thanks to Adam for proofreading!

Coming up with good personal projects - Part 1: Inspiration

ladyofcode — Tue, 04 Apr 2023 14:00:00 +0000

Approaching the crux of the project

Contrary to popular belief, a project need not be helpful to other people. If creativity is one of your core personality strengths, tossing aside the notion of usefulness now and again in favour of joy would do you good.

Let's get into it.

What makes a project good?

A good project is one that properly serves its purpose. So first things first:

Why are you doing this project?
Who is the audience?
What are you communicating to them?

Explicitly specifying the reason is essential as that'll dictate the type and scope of the project you undertake. You may want to:

Demonstrate capacity: strengths, variety, upskilling, etc. These often go into portfolios.
Satisfy an emotional need of yours; perhaps you enjoy a challenge and find it fulfilling. 'Because I can' is an attitude plenty of creators have.
Generate income; whether it's for stability or fuck-you money, both are still valid.

You could end up with something like:

As an unemployed designer, I want to showcase what I'm capable of so potential employers understand the breadth of my skill set.
As a junior developer, I want the ability to build a robust authentication system so I can aim for specific roles above my experience level.
As a homeowner baited by the very tech I love yet hate so much, I want to program my blinds to open in the afternoon to quell my desire for an anti-hustle culture rebellion.

Did I just user-story a project idea? Yes.

(Did I just use user-story as a verb? Also, yes.)

((Do you need to do that? Ye - No. You do not.))

Tailoring those projects will involve scoping and adjusting the technical depth. Scoping should include 'termination' criteria; when would the project be considered acceptably finished, and when would this be? Detailing this will be approached in Part 2.

Side note: If you intend to make money, validate that potential opportunity against customers from your market segment, i.e. you'll need to treat it like a business project, not a portfolio or passion-only piece. When they say 'execution is everything,' that includes making practical business decisions and solving problems in a way that eventually generates revenue.

Finding inspiration for projects

Solve your own problems

In other words: if you find something inherently annoying or inconvenient, see if there's a way to fix it. Even something small and niggling is a great place to start. Look at your daily routine, hobbies, and other things you may enjoy - or really don't enjoy. It's okay if you chuck this onto GitHub and it fades into oblivion over the next ten years, forkless and lifeless. It served its purpose.

Look for patterns of problems

Finding these patterns requires being observant of the people around you, what annoys or inconveniences them en masse, and some level of knowledge on a specific topic or field. You need that combination to figure out what makes their lives easier.

Don't solve problems other people have by solving problems for yourself. Pick one.

Project-based courses and tutorials

There's no shame in it: pick something new to learn and follow along. Ensure you're actually paying attention instead of going through the motions. You could:

Summarise content in your own words
Blog your progress
Struggle through tasks before you go for the solutions
Play videos at normal speed to consider more deeply

Additionally, consider customising the project enough so that you don't end up with a cookie-cutter project in your portfolio if that's where it's going.

Idea generators and online lists

Go ahead and try out a bunch of them to spark ideas. Remember you'll need to flesh it out and scope it appropriately before embarking on the project. Many of these lists online are general; find a way to customise the project to your needs.

May the force be with you

Thanks for reading! I'll see you in Part 2 for planning and scoping. Feel free to catch me on my streams or in Atlantis if you'd like to chat about your projects. Good luck!

Useful resources

Special thanks to:

Mahmood for the link to Build your own x
Alom, Colin, Adam, and Mom for feedback on my writing