This concept exists outside of engineering too. It's captured in the more negatively intentioned: ““The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer". In user research, it's a much better signal when people correct you than when they agree. Politeness is easy—especially under the circumstances (power dynamic of you paying them, they only half care about your work, people generally want to be nice/agreeable, etc.)—such that you should be weary of it. Similarly trying to get real project goals or real requirements or real intentions from a PM or a boss, who may well be hiding that they there isn't much vision underneath things, is the same. The problem is that as productive as it is for developing the team's thinking, it will (1) probably come off as unproductive and challenging because you're slowing "progress" and (2) saying dumb wrong things makes you seem dumb and wrong. But per the concept, even when you do have the foresight to question, you're not allowed to just ask.
The author suggested that if senior leadership had a development background then tech debt would be easier to get support and resources to deal with. Between the lines I'm reading that the risks are just inherently understood by someone with a tech background.
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
Being a CEO isn’t all that different from being a parent of a child from the POV of impactful decisions.
How many critical “parental decisions” have you made in the past week? Probably very few (if any), but surely you did a lot of reinforcement of prior decisions that had already been made, enforcing rules that were already set, making sure things that were scheduled were completed, etc.
Important jobs don’t always mean constantly making important decisions. Following through and executing on things after they’re decided is the hard part.
In the beginning of the day, don’t look at phone or computer. Avoid news especially, and instead write thoughts, draw something, work on a song, make something, anything. Don’t let day get sucked away with things that can’t be controlled.
Excercise every day with “scientific 7 minute workout”. Also 20–40 minute walks or 100 basketball jump-shots.
Draw daily, even a 5 minute drawing.
Write daily, even for 5 minutes.
Publish first original song, publish first EP. Learn a new song or practice one or two from existing set. Keep learning piano by learning songs you like: https://hypertexthero.com/piano/
Write postcards to people.
Set up a weekly “office hours” livestream to help people with design or technical computer issues.
Context: I was an early strategic technical hire by a director/manager/CTO 3 times to help execute process changes and lead new initiatives healthcare SaaS companies between 2014-2020 and then started working in strategic cloud consulting since then where I am brought in to get developer, operations and the “business” to be better aligned and/or to lead new initiatives.
I’m currently a “staff software architect” at a 3rd party cloud consulting company.
What not to do:
1. Disrespect current processes. What you call “legacy code” was done for a reason, is generating revenue, solving real world problems, and the reason you have a job
2. Make any suggestions about improving processes before you have been their at least 90 days and understand why the current system is like it is.
3. Suggest rewriting something or introducing new to the company technology until you have worked there 90 days. Especially don’t start doing resume driven development.
What to do:
1. Set up a meeting with sales and ask them to “sale you the value proposition of the product as if you are the customer”. Ask questions as if you were a potential customs and raise objections to the product as if you were customer. Sales is usually very good at answering those questions.
2. Talk to your manager and ask what are their 90 day and 1 year plans for your team and make sure your work is aligned with the goals.
3. Get to know the pecking order. The org chart will not show you who has the most influence in your department.
4. Setup “getting to know you” 1-1’s. What are people working on? What do they want to be working on? What are their biggest pain points? What would they improve if they had a magic wand?
5. Pick up small stories, bugs to get familiar with the development process.
6. Learn about pre-wiring a meeting when you are trying to suggest changes. Do a POC, talk to the person who might have the biggest objection or has the most influence and work collaboratively to address their objectives. Keep doing that for more people on your team. It helps get more people on your side.
There’s a reason most business and technology tools target enterprise and not SMB - the economics don’t work to target SMB. It’s much easier to convince a middle manager at some bigco to buy your solution for 100k than it is to convince 100 small business owners to buy your tool for 1k.
It’s not just about a more difficult GTM motion. Support and back office costs are actually higher as well. All of this makes it much riskier to go down market.
Maybe the first thing we need is not more tools for SMBs from companies doomed to fail from the beginning, but a platform that would enable these startups to efficiently serve the SMB market and address these fundamental problems.
On the practical side of things, one important behavior that I see people frequently forget is the importance of following up. This is probably the biggest differentiator between relationships that languish in the early stages, versus those that progress along the author’s continuum.
It’s always a bit strange when you only hear from people once every few years, just as they need an intro or career advice or whatever- the beginning of those conversations is usually a bit of sheepish catch-up on what happened after you last spoke with them. Similarly, there have been times when I have felt like a dope after realizing that I failed to follow up myself after a call, and am again reaching out for another reason.
However, when you follow up with someone as simple as “Thanks for connecting me with so and so, we had a great chat” or “I tried that thing you suggested, here’s how it worked out”, you build mutual trust and enthusiasm for a successful outcome to the conversation you had. It’s a genuine and thoughtful way to grow your relationship.
Dom from the video here. Fair point. Let me TLDR the lessons:
• Launch early and iterate
• Passion matters
• Market before launch
• Product-founder fit
• No marketing, no customers
• Repurpose failed projects
• Curation sells
• Digital products take time
• Side projects don’t need profit and keep you motivated
• Swim with trends
• Growth takes time
• Iterate relentlessly
• B2B > B2C for bootstrappers
• Scratch your own itch
• Great ideas come from problems
- migrations always run longer than expected. In my case, leadership estimates were off by a factor of 10. What the eng manager originally said would take 3 months ended up taking a couple years.
- try to deliver quick wins and incremental value. This is often hard though. But it’s worth a try.
- Try to avoid this becoming the project everybody attaches their pet projects too. It’s too easy for people to make this the project where they use that new framework, test well, set up a design system, and make lots of little changes.
- that being said: migrations are easiest if you keep the design (visually and engineering) exactly the same. There will be lots of pressure to “just redo it while you’re already having to rewrite it”, but the uncertainty of a redesign really slows things down. Having a reference implementation means you don’t have to invent tons of acceptance criteria from first principles.
- as soon as things start getting delayed, which they will, try offering to cut corners or cancel the project. You want somebody else in corporate to stick their neck out to extend the project.
- Try seeding the team with more veteran ICs internally. You’ll need their help as you uncover dragons or need to get other teams to help run or integrate your new code.
- Among projects I’ve seen like this, the person running them gets fired or quits partway through at least half of the time. This is often because some middle manager made a promise they couldn’t keep to executives, and needs a scapegoat to save their own job. (It’s often that kind of middle manager who switches jobs every two years and keeps failing up silently and the project delay happens halfway through their stay at the company and they’re just trying to get to the two year mark and quit before anybody realizes what is going on internally.)
I am not an Outstanding Programmer, but I like the advice on productivity from Jonathan Blow, paraphrased: "you don't need time management or productivity tips. If you want to complete a project, maximise the time you spend sat on your chair, with the editor open." That's all there is to it.
The best way to build a cathedral is one brick at a time. Effort and consistency trumps all. Being a 10x developer has no effect whatsoever on what you can accomplish in work or in life.
Great article. I've worked with Parquet files on S3 for years, but I didn't quite understand what Iceberg was, but the article explained it well. It's a database metadata format for an underlying set of data which describes its schema, partitioning etc.
Most people use Hive partitioning convention (i.e. directory names like /key3=000/key2=002/) but Iceberg goes farther than this by exposing even more structure to the query engine.
In a traditional DBMS like Postgres, the schema, the query engine and the storage format come as a single package.
But with big data, we're building database components from scratch, and we can mix and match. We can use Iceberg as a metadata format, DuckDB as the query engine, Parquet as the storage format, and S3 as the storage medium.
If you’ve ever tried to make a mathematical animation (think 3Blue1Brown), it’s a real pain. I was using manim for awhile to make animations for my YT channel, but the whole iteration process felt very slow and repetitive. So I thought I would recreate manim over the weekend, except with a GUI and real-time feedback. It’s been a year and a half and I’m hoping this weekend will be done soon so I can move on and start making videos again.
So far, it does a lot, but it still needs a lot of polish and refinement. The readme gives some gifs and a better idea of the feature set right now.
