X banned me 2 weeks ago, f them

I woke up one morning and out of nowhere my account was suspended for suspicious activity. I appealed it, sent multiple messages to X over the course of the past 2 weeks trying to at least pry the reason out of them if nothing else.

No response. Years of audience & network building, 1,300 followers, many of them online friends, all gone. They even still charged me for the damn blue badge while I was suspended. I was livid to say the least.

But there’s a glass half full here. I was spending countless hours on X every week. Definitely over 5, probably often up to 10, sometimes maybe more. A lot of it got replaced by Reddit now, where I honestly get much better engagement as you can see below.

The glass half full is not Reddit tho. It’s this. This blog post. This newsletter.

I remember many years ago when I was but a mere website builder I would always pitch to my would-be clients: own your digital footprint, any social media can ban you at any time.

Is it poetic that I get to live it now? Lol. The point is I want to use it as a lesson. I want to use this as the kick in the butt I needed to truly take building a blog/newsletter seriously.

Ngl, I am using Beehiiv which does come with its own platform risk. But Beehiiv makes it easy to export your posts and audience regularly which lowers the risk enough for me.

Who am I and what will this newsletter be about?

If you’re reading this, there’s a strong chance you already know me. But, I’ll take the time to re-introduce myself and give you the down-low of what I’m about and what this will be about.

I’ve been a software developer for almost 6 years now and working in crypto for the past 4 years. I started from nothing: knew nobody, knew nothing. I managed to self-teach myself how to code and to build a small online network, eventually becoming a tech lead at the company where I currently work at.

I imagine some day I will own a business of my own. Not exactly sure how that will look. Maybe a dev shop? Maybe a SaaS? Maybe a crypto project? Suffice to say, I’m ambitious, career-driven and perpetually dissatisfied. Not in the depressed & unhappy way though.

About the newsletter, the tagline I’ve chosen reads “Technical (and not so technical) deep dives on what I & the industry is actually shipping”.

That means you might see me talk about a side-project I’ve built or am building, like Minerva or Bumble Bet. Maybe I interview someone on my YT (like I did with Nick from Fuel Network) and write about my learnings from the interview here. I might comment on relevant tech/crypto news or market moves too, but probably not a lot tho.

I might even show you that dollar cost averaging into BTC is probably a better strategy than picking memecoins:

The above chart shows the returns of all possible 60-month periods (from 2013 till 2025) where you could have DCAd into BTC. You can see that even though you’d have had to stomach the volatility that BTC is known for, you’d generally come out ahead with quite a nice ROI.

Of course, this is not investment advice and past performance doesn’t always indicate future performance, yadda yadda. I still find that I enjoy a bit of data science (if you can call it that) in my life, so you might see some interesting charts here and there.

I also want to point out that this is not a daily or weekly newsletter. It’s an “I write when I have interesting things to say” sort of newsletter. Which leads us into…

What’s been going on in my life?

Let’s start off strong: last winter I got laid off and found out I’ll be a father. I have to admit it was stressful, but I knew it’ll all come around.

I did a short foray into the AI world, met interesting people like Matt and built Minerva (a self-hosted RAG processor API). My overall conclusion is that AI is just as hype-driven as crypto, only less open and more punishing ($ wise) to global remote devs.

Eventually, through a friend (CD security), I met Heinz who needed a team lead to help him build a social staking protocol on Solana for a client (Paragon). I had some minimal experience in Solana and a few dev friends who I knew were available for freelance work. For him, because of the referral, that was enough.

The product is quite interesting because it creates downward pressure on the supply (like any staking protocol does) and upward pressure on the demand because users only get their rewards if they post/like what the admins want on social media, therefore promoting Paragon.

In January we kicked it off with me writing the initial design docs and asking around for devs. We had to battle some scope creep here and there, but by week 10 the smart contracts (Solana programs) were done and in June we were devnet deployed.

The project unfortunately didn’t make it to mainnet yet, we’re still waiting for the green light on a series of audits. But the Paragon team liked us so much that we became more integrated with them and we are now working on a Rust trading bot for them.

Legacy systems with spaghetti code & 0 test coverage

This Rust trading bot was here before we were here. It is an unfinished project that an external team coded for Paragon. I say “unfinished” not because it doesn’t have the right features, but because it is completely unreliable/buggy.

At the moment of us inheriting it, we are talking about 27,000 lines of Rust and 6,000 lines of TypeScript code that had 0 tests.

I want to repeat that: 0 tests! And this code is supposed to handle money!

We are also talking abstractions over abstractions where you often had to go through multiple functions and classes and files and modules to figure out what the execution flow actually is.

We are talking not having a CI formatter or linter. We are talking almost 0 documentation. We are talking random commented code all over the place.

Not even setting up your environment and variables was documented. I spend 2 weeks before I could finally say I had it working fully locally because random actions would still break due to not having the right env vars.

There was bad separation of concerns. Not as in “things aren’t separated” but as in “this API returns raw error data from the smart contracts it calls and then the caller has to decode them instead of the API returning a neat use-able message”.

Insanely convoluted. In hindsight, maybe I’d have suggested a re-write. But by the time I personally realized how bad things were it was too late.

It’s been a month since I’ve been leading the effort to clean this up and a few months since we had devs of our own on it. I can’t say I am seeing the light at the end of the tunnel yet, but at least I’ve managed to convince everyone to stop feature requests and focus on tests & cleanup.

It was worse before I came in because nobody had the guts to halt the whole thing or the desire to make it testable and write tests. They were running in circles: fixing one bug which caused another to surface.

I guess my piece of advice to you if you ever have to inherit a codebase and the gut feeling is that the code is probably not great is to first take a few weeks and your best devs to audit the damn thing.

If you find it’s bad and you don’t want to or can’t rewrite it: arm yourselves with tremendous amounts patience across the org and plan to eat the elephant one spoon at a time.

Hiring and firing is hard

During this period as a tech lead I probably spent half of my time coding and the other half doing management and I’d like to think I’ve learned a bit about leadership.

A big part of being a leader is to keep the team happy, shielded and focused on what matters (i.e.: shipping impactful things). If you have a solid manager, like I do, there’s little to shield them from and it’s easy to give them the things that make them happy: challenging work, time off when they need it, as rare as possible crunch times, a good salary.

When your manager is great and your team is great and there are no crazy events going on, leadership is easy. Things just work.

But it’s very easy to hire “bad apples”. I cringe at myself saying this, trust me. But there really are bad apples out there. (I’ve been debating on keeping this line in for days, sorry, but it’s true so I have to leave it in)

There are "on paper seniors” out there who may write decent code, but are really not seniors. They don’t drive architectural decisions, they need well defined tasks to get going, that sort of thing. Overall too much hand holding.

I had to live through the quite stressful situation of making the decision to fire 2 such engineers. It was hard. I gave second and third chances. I tried to coach and be nice. These are people after all.

But, ultimately, this added significant extra workload on me and on the other seniors who are “managers of one”. It created drag on the team and it truly was unfair to everyone else, especially in a round table environment like ours where we all get paid the same (and we get paid well if I may say so).

So, how do you know not to hire these people? Well, you don’t. You can do as many interviews as you’d like, there’s no 100% guarantee you’ll know until you work with them for real.

This is why I’ve converged on this hiring process for now:

1. quick (likely written ‘cause I love being async) chat about candidate and the role + resume review

2. a 4h take-home (list of take homes I’ve used before) relevant to the work that would be done on the job (or if they can present relevant public code they’ve written, that’s also good)

3. a 1h interview where I try to get some “war stories” from their career and get them to talk about how they’d architecturally design something relevant to our work

4. a 1-month probationary period where both parties decide if they’re a fit

To me, this seems ideal. You can get #1-#3 done within 2 weeks if you have a decent pipeline of candidates. It will all act as a series of nets: some people get disqualified at #1, some at #2, etc. And, then, at #3, you can judge the 2-5 final candidates and give one or two of them a shot. Worst case, you re-start again in 1 month.

It feels fair to the candidates as well. I’ve been through far more intensive interviewing processes before, some spaning months.

Of course, some candidates might say even this is too much and I respect that. In all honesty, I got my last 2 jobs without a technical interview all based on someone telling someone else “Alex is good, hire him” and we do take referrals very seriously over here too.

Outro

I hope you’ve enjoyed reading this, maybe even learned something from it.

As I said, I don’t know when the next email/post will come. I’ll be pretty busy in the following period as we’re in the last pregnancy month and the baby can come at any point now.

Whether we already know each other or not, do feel free to contact me at any point with anything. I’d love to help if I can. You can find my contacts at https://alexlazar.dev/, the one place I own and will never ban me, lol.

P.S.: The pic here is taken by me on the Romanian seaside. Had a fun time there for a few days a few weeks back.