https://ladyofcode.com/rss.xml

Although I ditched the idea of New Year Resolutions in my early 20s and joked that my New Year’s Resolution was not to have New Year’s Resolutions, it was only recently a smidge of smugness set in.

I still goal-set up the wazoo. In fact, I do celebratory recaps and yearly goal-setting with friends; I even designed a lil low-effort program for it. If I wasn’t intentional my life would be chaos without direction i.e. more stress, less fun.

It dawned on me just ten years later that my rejection of New Year Resolutions was the first step towards developing a healthier relationship with failure.

New Year Resolutions elevate the importance of the streak over the goal. The quality of momentum is reduced and the reasons for the goal are diminished. There’s no fallback mechanism for when the streak breaks. Breaking the streak feels even worse because this was the new start. It was special. Even if it was just as special as all the other new starts. 💀

I schedule 100-Day Challenges on Jan 1st, but also on May 1st and September 1st. Counting from 1 is convenient (who’d have thought? lmao). I plan in weeks but I execute whenever. Nobody cares, including me, if I begin on Jan 18th. What day of the week is that, even? There’s no *waiting* for the next New Start. If it’s important enough, why not now?

I also don’t stop counting because I missed a day or two. That’s just life.

People often pick lofty goals for resolutions, like going to the gym – goals tied into identity that require habits when a hijab would’ve sufficed.

In a similar vein, my biggest accomplishment from last year is that I’m now someone who exercises. It was *the* most basic human thing on my spreadsheet 🤣. When I wrote the goal down the intention was simply to develop the habit.

When I began it was some arbitrary day after a series of inward realisations. Even though I dropped the ball completely at one point, it was a very simple system that made the habit stick:

• Exercise daily.
• Life Happens, and when it does I get up to two days to get back on track.

I’ll use whatever I have at hand.

When I don’t exercise, I observed direct consequences: Sleep quality drops the same day, I feel more stressed, and I don’t burn enough calories to compensate for sweet treats. I get told my militant dedication to fit a workout in daily (5 AM if I must) is admirable but it simply *feels* like I’m treating myself with basic respect.

Goals have various approaches, but there are combined characteristics to make them happen. New Year Resolutions tend to exist as an expression of desire; they’re not seriously treated as goals, and failure stops progress in its tracks. The feedback loop I created above is absent, which feeds into intrinsic motivation:

This was a small and mostly insignificant conclusion. But this is my blog and I do what I want. I’ll be linking this to the lovely people who join me in chatting about goals come December.

May you have the energy to see yourself through the year. Loveyoubye.

Autonomy is the concept of self-governance—the freedom to decide without external control. Agency is the extent to which an entity can exert control and act.

We have both as humans, and unfortunately LLMs would need both to have true artificial general intelligence (AGI). This means that the current wave of Agentic AI is likely to fizzle out instead of moving us towards the sci-fi future of our dreams (still a dystopia, might I add). Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027. Software tools must have business value, and if that value isn’t high enough to outperform costs and the myriad of security risks introduced by those tools, they are rightfully axed.

The rush to integrate large language models (LLMs) into production applications has opened up a whole new world of security challenges. AI systems face unique vulnerabilities like prompt injections, data leakage, and model misconfigurations that traditional security tools just weren’t built to handle.

Input manipulation techniques like prompt injections and base64-encoded attacks can dramatically influence how AI systems behave. While established security tooling gives us some baseline protection through decades of hardening, AI systems need specialized approaches to vulnerability management. The problem is, despite growing demand, relatively few organizations make comprehensive AI security tools available as open source.

Is this your first foray into AI red teaming? And probably red teaming in general? Great. This is for you.

Red teaming is the process of simulating real-world attacks to identify vulnerabilities.

AI red teaming is the process of simulating real-world attacks to identify vulnerabilities in artificial-intelligence systems. There are two scopes people often use to refer to AI red teaming:

A system card accompanies a LLM release with system-level information about the model’s deployment.

A system card is not to be confused with a model card, which conveys information about the model itself. Hooray for being given far more than a list of features and inadequate documentation along with the expectation of churning out a working implementation of some tool by the end of the week.

LLM breaches jumped 180 percent in the last year. If you ship AI features, you need a one-page map of the dangers—and the fixes. This five-minute TLDR walks through the OWASP Top 10 for LLMs, from prompt injection to unbounded consumption, with concrete mitigations you can copy-paste today.

As AI technology advances, so must security practices. System prompts drive AI behavior, so naturally, we want these as robust as possible; enter system prompt hardening. Increased reuse of system prompts affects their prevalence, affecting the number of attacks to manipulate them.

No one would look at their AI’s mangled output and decide ‘Maybe the real treasure was the prompts we made along the way’ with the problem being the opposite.

Let’s dig into system prompts while secretly lamenting someone’s unfortunate choice of phrasing for this technique.

Technical writing… I almost want to say ‘how hard can it be?’, but I immediately suspect I’d follow that up with a ‘famous last words’ at some point in the next few months.

My original intentions were to write notes from Board Infinity’s Technical Writing course as an in-depth review. This ended up being fruitless due to the course being geared towards beginners - which I am not. Instead, I’ll contextualise some thoughts I had throughout the course.

I have what I hope is valid confidence in my capacity to write. My grasp of English is rock-solid due to a fortunate set of circumstances. I’m able to write with a prominent authentic voice. Those things are not enough to be a great writer. There are many kinds of writing, and each is accompanied with skills that must be honed to a sharp edge.

I have written research proposals, project documentation, technical specifications, and plenty of community guides. Most of these are over five years old (some are university assignments - shudder) and likely not up to standards I currently harbour. This leaves me starting this section of my writing portfolio from scratch; a daunting yet achievable task.

In beginning this technical documentation journey - which I will no doubt find bereft of linguistic flourishes that bring me joy - my goal is to highlight improvement zones, rank them, and derive a plan of action.

The key takeaway from the course: technical writing is about utility. Clarity, conciseness, and logical ordering reign supreme. A fair bit of the course describes the different types of technical documents, how they’re structured, and the process used to go about writing them.

I was surprised to learn about the intersection of writing, design, and entrepreneurship. They all take the audience into account at a deep level. The course mentions typical surveys, questionnaires, and user interviews to solicit user feedback. From my experience, they can be found in more places:

• Use a search engine to look for issues; sometimes people complain about it online in various blogs and forums
• Look at where people are struggling in online tech communities
• Look at how people use the content; I once had an author watch me go through his framework book on Twitch and try to build; this was helpful for additions

I groaned when I encountered reading material structured like a common Wattpad novels - one sentence in each paragraph.

Just one sentence at a time.

It gets rather annoying when reading it on a wider screen, does it not?

The cadence may be harder to notice on a smaller screen but it’s quite obvious now.

Okay, I’ll stop being annoying.

My unique set of experiences removes me from the target audience. The course is fantastic for absolute beginners. and I would recommend it to anyone who doesn’t understand much about writing and the context surrounding the role of a writer. It briefly touches on most important aspects of being a technical writer, which are numerous and extend well beyond the writing itself.

My experiences in design, entrepreneurship, academia, and coding already have me practicing these skills:

• Aligning content to a brand
• Write with planning, research, outline, drafting, revision and proofreading stages
• Building a style guide
• Competitor analysis
• Understanding audiences; demographics, psychographics, and segments
• Word-processing and referencing tools (MS Word, LaTeX, Obsidian, EndNote, Zotero)
• Graphic and design tools (Photoshop, Illustrator, Affinity suite)
• WYSIWYG, rich text, and markdown formats
• Version control like Git (GitHub, GitLab, BitBucket)
• Content management systems (WordPress, Drupal, Strapi, Decap)
• Management systems like Confluence and JIRA
• Search for keywords
• SEO topics

Things I can improve or learn to do:

• Improve overall SEO practices
• Draw more diagrams
• Localisation
• Distinguishing which types of charts or graphs would be appropriate
• Headline generation (I currently don’t do anything formulaic)
• Run a content audit
• Identify content gaps
• Competitive analysis (not to be confused with competitor analysis); understanding when to go broad versus specialist with topic coverage
• Bearing in mind industry-specific code of ethics

A lot of that isn’t actually about the writing itself, which was more of what I was looking for. The course was still useful for figuring out gaps in my knowledge. Copy-targeted content should crop up in Google’s Technical Writing course, which I endeavour to complete as soon as the sessions are available.

The most valuable thing at this point for me would probably be feedback on things I write. I may just hire someone to have a look - unless you know someone?

Thanks for reading!

Image credit.

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?

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?

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!

First things first:

1. Listen to your body.
2. Don’t get other people sick.

I write this article having fallen ill a week ago, home-bound and literally voiceless. I advocate against working while ill and believe people should rest most of the time. I, however, do not quite follow this advice (‘do as I say, not as I do’). If I’m staring at a screen anyway I’d lament any stagnation of my endless to-do list, dwindling into a muttering mass of productivity nihilism. This article is for people of a similar ilk.

Willingly working in a poor state of health should be done for personal benefit: if there is none, don’t do it. If you feel you have to work while ill, that’s a red flag; condolences to anyone with tough living situations or toxic workplaces. Working while sick means we make personal sacrifices, so doing it for ourselves is the only reasonable situation.

Energy should be focussed on your health first. Being unwell means the ability to do most things has waned. Don’t do silly things like promise deliverables or anything that’s delivered at your usual capacity.

Rest and sleep are important. If we don’t let our bodies do what they need, we slow down recovery and lower our capacity to do anything, not just work. Don’t feel guilty for doing the thing we’re primarily meant to be doing, which is recovery. Some days we feel very little was accomplished and that’s fine; our body’s battling away at other things we can’t consciously put effort into, so whether we want or not we still made progress.

Tone down everything in the schedule; push back everything manageable. This includes chores. If the laundry basket is overflowing, it’s okay - you’re not going to be left battling a laundry mech over that sock that’s been missing for three months.

If you happen to be privileged, use it: order food, groceries, laundry services, literally anything that would’ve taken you time otherwise.

The point is that some things have to shift somewhere. There simply just isn’t energy for everything. If you can’t make the time and space for work on top of healing, then pleeeease ditch trying to work, and focus on healing.

Further to point 3, this is definitely not the time to try to do everything yourself at your usual capacity. If you are lucky enough to have people around who want to take care of you, LET THEM. Normally people who love us help us anyway regardless of what we’re doing; personally, I feel I owe it to them not to be especially burdensome. We’re both Team ‘Point 2. Prioritise Your Health’, so I avoid making any decisions that would lead to deteriorating health.

Remember: there should be a benefit to working under abnormal health circumstances; if it is not therapeutic or bringing you peace of mind, stop. You need a tolerant, full-health you to deal with stress and hot messes.

Stay well, and don’t let your posture mimic that of a shrimp!

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.

See YouTube video ‘Brené Brown on Empathy’:

https://www.youtube.com/watch?v=1Evwgu369Jw

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.

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:

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.

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!).

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’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 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.

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.

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!

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. 💀

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, 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.

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 💖

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:

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.

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 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 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.

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.

 -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.

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.

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.

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!

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 following scenarios I give are not exhaustive. Here are some languages and stacks I’ve recommended based on people’s situations:

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.

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.

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.

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.

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.

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.

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)

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.

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.

’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.

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.

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.

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.

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.

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.

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.

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:

1. 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.

1. Define the project’s deliverables

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

1. 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?

1. List constraints and exclusions

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

1. 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.

1. 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.

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.

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 to Adam for proofreading!

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.

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.

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.

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.

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.

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.

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!

• Awesome lists about all kinds of interesting projects
• Build your own x
• Collective list of free APIs
• Public APIs
• Web development resources
• Sharpen: Open-ended project prompts
• App idea generator
• Designercize
• What should I design
• Daily UI
• Daily Logo Challenge

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

I’ve been reflecting on my learning tech over the past five years. Like most developers, that’s included a vast array of tools and tech. Most of the following observations result from my interactions with Gatsby, Strapi, GraphQL, and tangential tech. I’ve also used tools that remained… Low-key.

Bear in mind this is more of a dive into the things I most appreciated and my decision-making process rather than a comprehensive analysis:

The first thing users want to know is whether their key problems will be solved or not. Products communicating that were clear about it on their landing pages and:

• Included blog posts covering common use cases for building blogs with similar functionality.
• Provided shortcuts to common configurations of a final product. Skeletons, starters, and so on.
• Provided plugins for integrating other libraries and tools into the software.
• Provided well-designed and aesthetically-pleasing versions of various implementations of a product.

The sheer number of Gatsby plugins covering my needed functionality helped my confidence; funnily enough, this reminds me of why I used to pick WordPress for launching projects. Back in 2018 I was less familiar with React; as a result, I found inspecting Gatsby Starters immensely helpful. It seemed aesthetically pleasing UIs were downloaded more - likely particularly appreciated by people who haven’t honed visual design skills.

New users in this context include experienced and inexperienced users; as long as they’re new to the product. Content posted included:

• This should be obvious: robust and well-written documentation (concise) is a requirement for anyone navigating their way around software tools.
• Tutorials covering integrating the product with other technologies - especially the more popular ones.
• Updated tutorials, which were even better to find.
• Tutorials written in such a way that makes it easy to get started but still offers specifics to delve into at a later date.
• Incredible documentation genuinely made for an enjoyable experience.
• GitHub issues; resolutions with explanations were fantastic.
• Code written in a core language so it’s easy to decipher and implement; the code becomes easier to troubleshoot when something doesn’t match up.

Tutorials accounting for 80% of what I needed to implement functionally for a project was the tipping point for my decision to run with GatsbyJS + Strapi as technologies new to me, as opposed to something like WordPress I could already use. The remaining 20% was mostly due to available documentation and assistance. I never thought I’d find a version migration enjoyable, but here we are. 💀

It was challenging to follow TypeScript examples when learning something new; the syntax was confusing when I wasn’t all that familiar with it and didn’t have a developed mental model. Plain JavaScript better supported the learning process. Similarly, minimal implementations should be just that; even Tailwind can make things difficult to read for people who aren’t used to it.

I found this particularly unhelpful: providing a bunch of files to copy and paste without explaining much. One may as well link the repo with a script at that point.

I usually try to get by with as little direct help as possible. It’ll be necessary at different levels though - from people interested in a product to current users with advanced problems. Product teams ensured they:

• Built a helpful community across various platforms. Being able to ask for help in both forum form and chat is beneficial, even if this process requires streamlining later.
• Enabled and elevated active members to assist others with the product.

In order to arrive at a solution, I’d consult resources in the following order:

1. Documentation
2. GitHub issues
3. Google for tutorials
4. Chat app/forum (whichever was more populated)
5. Ask for help in chat

Strapi’s community made a significant effort to help people (shoutout to Derrick Mehaffy, thank yoooou), and that made it so much easier for me to overcome some of my roadblocks. Another tool had a Discord server that wasn’t particularly helpful, so I began avoiding it for the most part. The result was no chance of me participating in their wider community. Slack was horrible sometimes; I’d go looking for issues but the free tier prohibits searching beyond 10k messages.

A few other points of impact:

• The tools that grew were updated regularly, communicated updates frequently, and offered well-maintained newsletters and updates in chat channels.
• Presentation of a product matters to some degree. A well-designed user interface affects the perceived user experience and professionalism of a product.
• Product teams conducted user research interviews. Having participated in one, you can tell how seriously they take addressing user needs. Side note: I was impressed and appreciative to see developers conducting these in addition to designers.

There’s something to be said for building tools that ‘fit into the mainstream’. Tools that slot into the React ecosystem, for example, and suit the needs of many people have a much higher likelihood of increased adoption due to the sheer volume of users. I mention this because it should be taken into consideration for comparisons.

Strapi has raised USD 45 million in funding to date, and Gatsby USD 46.8 million, both in Series B funding rounds. While solving core needs is at the crux of it all, it’s clear the people at the helm clearly understand that their products exist in the context of a wider community and that decisions are made accordingly. These products have evolving business models; they’re not just tools in a vacuum. That’s something anyone building a product to serve others would do well to remember.

This planning process actually happened during stream, where I made all the following decisions and set up a workflow on Trello. Here lies my first tweet.

Roughly, items I will post will consist of:

• Articles: technical stuff on my Lady of Code blog, self-development stuff for System You
• Newsletter: personal ^ including above stuff [Links, Atlantis, challenge, pun/joke]
• Twitter threads: writing tips, summaries of articles/topics
• Writing drills (as a break)

Side goals:

• Launch System You (so that means design + launch alpha)
• Prep newsletter content months in advance

Some rules:

• If I haven’t looked at how to improve my writing, default to posting every Wed for a Twitter thread
• Newsletter post at least once monthly
• Article post at least once monthly; drafts I can do in chunks whenever

Some starting deadlines:

• Sep 2nd — 1st Article
• Sep 9th — 2nd Article
• Sep 9th — Writing article drafts
• Sep 2nd — First article
• Oct 1st — Newsletter

Blog updates:

• New categories (self-development)
• Add captions for images
• Check alt text field for images

The plan is expected to evolve over time, as these things usually do. Thanks for checking this out and let’s hope I stay consistent with this 100 Days Challenge as well.

Good luck to everyone!

Look, I had to.

Like many devs thinking we’re funny and nerdy, I’ve titled posts similarly every time I joined a new platform since my teens in order to pass initiation into the cool kids club (nerds are cool and I refuse to be told otherwise). It’s practically a bug we’ve all got at this point. Anyway - this is me committing to being non-committal about writing blog posts. I’ve put it off for long enough.

So if you’re reading this - and I’m not sharing it anywhere publicly, which means you actually had a look at my posts - thank you for taking a gander. If you don’t know me:

Hello! I’m Tabs (I use spaces), and I’ve been a tech person since I was a kid.

• I love design and development.
• I currently run a gaming guild (twelve years now!), and two interdisciplinary creative tech communities. I advise others on their social communities. I love community management, clearly.
• I run 100 Day Challenges (in my communities), a software architecture book club, and quite a few events.f
• I have a SaaS venture called Grid App to build chat-based community management software.
• I’m a firm believer in being a specialist generalist, and so I’m working to broaden my skillset out to fullstack while maintaining my specialisation in frontend and design.

You can find me on Polywork or streaming my projects on Twitch. I’m happy to chat on Twitter as well.

I invest a lot of time into learning and tons of opinions I need to shove somewhere. I figure that if I shove them into a blog it’d be a far calmer process for everyone 🤣. I’m told they’re helpful. If I can help others and perhaps hone a set of skills along the way, this is at least worth my while. In an effort to be less self-deprecating, I admit there will be probably some amount of value to people in my posts. I want to keep my expectations low so I’m not too disappointed, particularly because this is going to be a journey and a half. I hope to figure out what will be more useful and then write more of that.

Maybe one day I’ll be able to communicate well enough to feel like an article has transformed from a bug into a feature. 😊

Photography in cover photo by Mude Creative. Yes, that leather jacket is my only leather jacket and it is indeed rather prevalent at the Innovation ACT events photos throughout the years. 😜 I feel self-indulgent posting this collection but what the hey?