#codecraft — Public Fediverse posts

The Andy Dufresne project

Have you ever been stuck on an Andy Dufresne project?

You know the one. You’re trapped because of something someone else did, chipping away at legacy structures with just a rock hammer. And you might even have your own Rita Hayworth poster to hide the refactoring of this debt.

Sometimes that’s agency life. The promise of a rewrite (and your own boat in Mexico) if you can just chip away slowly and then crawl through half a mile of shit. It can be achingly slow progress, trying to get buy-in for your freedom, when the people with the power just want to keep you where you are. You’re trapped because of what someone else did.

And if you stay in that code too long, you’ll get institutionalised and won’t be able to see a better way to fix this problem.

‌How to keep making progress

Firstly, it’s much easier to survive a project like this if you have the right team beside you. People who can accept the faults and accept they’re temporary. You need a team of gardeners, not innovators, who can dig deep and understand what’s actually happening, where the rocks and the edge cases are. And who’ll take a break to listen to music or otherwise relax and take stock and look up.

And you need to understand the progress will be slow, but you can put guard rails in place so that each bit of progress you make has tests and is better than you found it. And sometimes you have to shake the refactorings out as pebbles amongst the other work because management and the clients don’t want to see it.

Never stop asking for freedom to make bigger changes, but always pair it with trust. They’ll listen more if you respect their budgets and their time, and you can explain what’s easier and what’s harder.

The Great Escape

If you do get the chance to rewrite, there may well be external factors at play. Use them. Digital transformation, going mobile, getting AI-ready. If you can tap into the strategy and find ways to align what you want with that, it’s going to be much easier to get approval. Be honest with the proposal, but always keep an eye out for those opportunities.

Look after Red

The only way to get the job done and get where you want to go is to take the important people with you. The ones who can get you a better hammer, or a new cover for the next bit of refactoring. Honesty will always get you further, so long as you know who to trust. Make it easy for them, so they can come with you on the journey.

See you on the beach.

Codecraft: Native Amiga IDE for Coding and Debugging
#Amiga #Codecraft #AmigaDevelopment #SASC #AmigaOS #RetroComputing #AmigaSoftware #OpenSourceAmiga
https://theoasisbbs.com/codecraft-native-amiga-ide-for-coding-and-debugging/?feed_id=2787&_unique_id=67fe59c52fedb

Codecraft - die integrierte Entwicklungsumgebung (IDE) von Camilla Boemann - ist in Version 1.16 erschienen.

http://boemann.dk/codecraft/

#commodore #amiga #amigaos #amigaworld #codecraft #ide #developer #coding #software #retro

CodeCraft Academy: Как я создаю открытую платформу для обучения программированию

Привет, Хабр! Я yukk1ro , и сегодня хочу рассказать о своем проекте, который призван сделать обучение программированию более доступным и эффективным.

https://habr.com/ru/articles/895802/

#programming #education #opensourse #learning #codecraft #academy #git #github #js #webdevelopment

As usual with my writing ideas, some constructs got stuck in the machine and I finally found the flow to make them stick together:

https://www.sounding.com/2024/11/15/finding-flow/

#DevEx #SRE #intuition #improvisation #insight #flow #FlowState #creativity #stagecraft #codecraft #DIY #maker #programming

Had a developer moment updating a project: "Man, this is no good; I should do something about it."

That's the judgy part. The part that wants to throw everything away and start over using my current knowledge, patterns, and understanding.

This is the distracting part.

The site still works. The code is well crafted for my knowledge, patterns, and understanding at the time. Time to start making notes of how to get "there" from "here."

#CodeCraft
#PHP
#SoftwareDevelopment
#TechnicalCoach

I'm starting to think one of the blind spots of strong type system proponents is the power of names #design #codecraft

Mise en place architecture

I love working with smart people. I learn a lot and it gives me energy.

I hate working with smart people who aren’t motivated. They’ll either get sloppy, get a new job, or get creative with their code design. The kind of creativity that makes you curse when you’re debugging a production incident at 3am.

The best creativity happens in a constrained environment, which also happens to make the easiest debugging.

Sure, we could let the developers figure out the best way to do something for every component, and there’s sometimes a benefit, but for every hour they’re spending figuring out how to solve a problem that didn’t need to be solved, or figuring out an unusual design, or evaluating a logging package, or writing boilerplate, there’s an hour not delivering value.

When an architecture is designed to put everything right where it should be, where decisions that have already been made are baked into the code and the tools, where a developer doesn’t have to think about how to structure their solution, the code is easier to write, easier to review and easier to debug.

Chefs like to follow mise en place. Everything in its right place. Before preparing a dish, prepare the workspace, the knives, and the food. Everything you need for the task and nothing you don’t. Everything is in a predictable place. Because then you can concentrate on the dish, instead of the kitchen. Good preparation helps every task fall into the pit of success, and makes it easier to recover if something goes wrong.

The more steps you have to complete a subtask, the easier it is to make mistakes. You might forget what the previous step was, you might walk to the fridge and then have to return to your workspace to remember what you need. Multitasking adds friction and adds opportunities for error.

That’s why we want encapsulated classes and single responsibility. One change updates one file, as far as possible. Although one feature may cover many changes in order to make it possible. Isolate your code from the data store, isolate the public API from your code, parse don’t validate.

Keep smart people working on solving new problems, and keep them consistent, because that’s the way to get the best from the team at all times, especially when you have a Priority 1 to update a logging framework at 3am.

Journaling for technologists

I encountered a question online recently about building context quickly, and whilst I thought of the bootstrapping post I made before, I also wanted to take a chance to explore how that plays into continuous practice. I started journaling as a researcher to remind me of all the dead ends and configurations I’d tried. Although I’ve not been entirely consistent in journalling (or sometimes blogging) each day and each new discovery, I think it’s a good practice for technologists to develop. Think out loud, even if it’s to yourself.

When building context on a new project, for example, I often find it useful, as part of discovery, to note what the client (or in very rare circumstances the written requirements) says it does, as well as what it actually does.

And always, always, journal everything. How to get it running locally, how to release, who knows what, who has the admin rights,… Anything that takes more than 2 minutes to figure out.

Sometimes that journal will take the form of shared content to help the next person join the project (and like all good scouts we should leave a place better than we found it), but the important bit is to write it for yourself. 80% of the time future you won’t need it, but that 20% makes the time absolutely worth it.

Possibly a crazy fever dream…but isn’t applying Single Responsibility Principle, and constraining function to a tightly coupled set of boundaries a similar concept to limiting work in progress? 🤔

#wip #srp #codecraft

@garyfleming If there was one, say, 'glasgow.tech', that might be a good.

I could see #CodeCraft Glasgow also joining it for example :)

I'm on #tech:glasgow.social and have not yet worked out if that is mastodon compatible or not.

No one thinks like you

Don’t make the mistake of thinking you’re the smartest person in the room. You might be the most knowledgeable about your specialist subject, but being a good boolean whisperer does not automatically make you an expert on public transportation, psychology, poverty, history, finance, or any other industry.

I’ve had the privilege of being disabused of that notion very early on in my career, surrounded by statisticians, linguists, psychologists, designers and vets. I do what I do, and let my curiosity take care of the rest.

But there’s a lot of arrogant arseholes in this industry who think they know best. Those who will talk instead of listening, who belittle, interrupt and condescend. They know their domain very well and are quick to criticise others who don’t understand.

But we all have our own models of how the world works, our own coordinates on the axes that describe the world as controlled by us vs controlled by others, whether money or relationships are more important, whether people matter more than animals, whether humanities can survive without science or science without humanities, visual thinkers or verbal thinkers or lingual thinker or kinetic thinkers. We don’t perceive or act in this world in a way quite like anyone else. We all bring unique experiences and perspectives to the table, and we all know something that others can learn from.

So sit and listen in silence. Take in what you can, and when you’re ready, ask questions. Listen to understand, not to respond, not merely to be polite, but because you are interested and you want to learn.

If we could see how others see us? They’re talking. All you need to do is listen.

Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

Demotivated by refactoring

Technical debt causes drag. It slows down new features and lengthens the half life of a project (Erik Bernhardsson talks about projects with a code half-life measured in years, but Sandi Metz talks about projects with a half life of 6 weeks on her Chainline mailing list – go sign up now). We all know the benefit of doing it and development teams fight to get time to do it.

But it’s not the most exciting work. Dealing with debt can easily demotivate a team fired up by new challenges and new features, even when they see the benefit. Yak shaving doesn’t get innovators out of bed.

Sometimes the motivation comes from seeing the next step, 2 days refactoring so that this new feature can be delivered faster. Sometimes it’s a negative motivation, fix this and you’ll never have to worry about it again.

But for teams driven by delivering business value, taking time away from that to naval gaze at the code stacks up the guilt, and can tire the team out faster than a crunch, because there’s no adrenaline to go around. That’s because often the goal of refactoring isn’t enabling functionality, it’s unlocking efficiency, and that’s a less tangible goal. Why go through the pain when other tasks show more short term benefit for less work?

For one, the team has to be motivated by medium and long term goals rather than just short term. Not just what can be done this sprint, but what code do we want to work with next year? For another, refactoring in general should be small enough that the next business value task is on the horizon, and directly linked to the success of the current task. Or maybe there’s a personal reward. The team appreciates the work and so is happy to cover your support shift. They all agree that you get off pager duty for the length of the task plus a week.

When yak shaving is a drag, how do you keep motivated?

Smart is subtle

In the spirit of bad interface design, there’s an overall principle worth bearing in mind. For all your smartphones and smart cards, and smart things, I sometimes feel very dumb trying to work them. They make me think too much. I used to have a Honda Civic, and when I chose that, I also looked at a Hyundai and a Ford Focus Titanium. One of the things that stood out for me was that the Titanium was overloaded with flashing lights and dials, and the Hyundai had lots of buttons. The Civic was just a nice car to drive, with a dashboard that wasn’t distracting. There are lots of smarts in the car, from auto-stop, to a hill-start clutch, but most of the smarts are in the background. Not just hidden, but working behind the scenes so I don’t have to think about them.

Remove the flashy lights, and the buttons no-one presses,and the options that you can automate. And simplify the rest. Boot by hiding complexity but by managing it.

Becoming a technical lead

A new year has arrived, and maybe now you think it’s time to take on a new challenge. You want to become a technical lead, or maybe you can see that your project needs one and no-one else wants it. You’re apprehensive, and unsure you’re ready. It’s OK. Everyone is an imposter.

Set yourself some stretch goals, something that seems just out of your reach. Throwing yourself in at the deep end is good practice, because you might ask your team to do it too, so you’ll be able to use your experience to help. You’d be wise to have a mentor at this point, to make sure you’re not being too ambitious, because you do want some early successes to give you the confidence you’re going to need later on.

I’ll assume you have the technical knowledge, so think about the things that set you apart, now you’re a leader. You have to guide the team to the goal, and make sure there’s a common purpose, and a team culture to follow. That’s all down to you. You have to know your team, and their strengths. You need a strategy to deal with disagreements. Read Peopleware: Productive Projects and Teams and understand that people are not interchangeable components, despite what your high-level plans might fool you into thinking. You are an individual now, your team are individuals too.

Ask questions of your peers and the community to understand what technical leadership means to them.

Learn from those who’ve done it before, and have offered up their wisdom. One of my colleagues is writing about his learning path as he goes, and there’s a lot of great information about keeping the bigger picture fresh, and understanding your team : Mike Childs – blog posts on leadership. But don’t forget to look after yourself too, as Patrick Kua explains : 5 Tips for Being an Effective Tech Lead | ThoughtWorks

Good luck on your new challenge, wherever you are.

The Constant Gardener : Knowing your team

One of the most interesting challenges in becoming a lead is understanding your team, and balancing project tasks between them. Whilst experience, both technical and domain, is a valuable indicator of how to assign tasks, there’s a few other things to take into account.

Having worked with a few people over the years, I can see 2 main types of developers. Managers may be asking which of the 16 Myers-Briggs personality types these represent, but I’m trying to give a persona sketch rather than a detailed breakdown.

Innovators are the ones I see most often – developers who want to work on the hot new thing, keep seeking out new ideas, and often like to throw things out and start again. They can pick up new projects quickly, by focussing on certain areas but are likely to get bored if they stay on one project for too long and may sometimes miss the bigger picture. That’s great for learning, and pushing forward the boundaries, but may not provide the stability that some projects need, and may need closer code reviews to ensure they maintain the house style for the project. If you’ve ever needed a white knight on your project, they’ll probably be an innovator.

Gardeners will take longer to get up to speed with a new project, because they prefer to dig in and find out how everything works, and build a detailed knowledge of the system before making changes. They will tend to evolve systems over extended periods. If you get someone like that on your project, you’ll want to keep them for several months, as their value to the project increases over time. Long lived projects with several maintenance releases benefit most from this type of individual. You may well find that they know the business domain better than the customer.

I think everyone I have worked with has qualities of both, but there are individuals who are clearly more innovators, and others that are clearly more gardeners. A good project should have both, with innovators pushing ideas and bringing new technologies to the tables, and the gardeners bringing the domain knowledge to make sure the right changes are made for the long-term health of the project. As a lead, your job should be to understand the way your team things, so that you can take the right ideas on board at the right time, and bring your team along with you. And, most importantly, know yourself. The most important thing the others on the team bring is knowledge of things you don’t know, or at least questions that force you to think about them. Embrace it. Inspire your innovators and nurture your gardeners.