I have the same experience, and I agree that simplicity leads to success. The more things software can do, the harder it is to reason about what it's supposed to do. It's very much the IQ bell curve meme: junior developers only solve the problem at hand, mid-level developers build powerful, but complex frameworks which can solve the problem at hand but also potential future problems, and senior "X10" developers only solve the problem at hand.
> There are times during the development of any project where one might be tempted to hack around an issue, or commit the ugly code that seems to work. These are the rough edges that inheritors of a codebase use as evidence that a blank slate would be preferable.
Yes, one thing I've learned is to never underestimate the power of inertia in a codebase. When adding functionality, 99% of developers will go for the path of least resistance, which is mimicking whatever patterns already exist. To loop back to the article, this is often due to lack of full understanding; the default assumption is that because something is written in a certain way, that it's the best way. This isn't true; it may not even be the correct way! But copying what already exists has an element of safety built into it, without needing to spend the effort to deeply understand existing code (which tends to be developers' least favorite activity).
So if you put in an ugly hack, or have a code structure which doesn't make sense, expect that to persist for years, or decades.
Well, don’t be cynical about it. One thing that I think a lot of us could benefit from is learning how to present a point in a way that people will listen. The key is to harness that hype — use your point to unlock some pent up energy for a new direction, rather than merely try to say it can’t work.
A lot of endeavors can work, even if only a little. Find some aspect of it that can, and flip the problem around. Even if the whole thing is mostly bogus, is there a small part that isn’t? Latch onto that.
Or go elsewhere. The wonderful part about AI is that the whole world’s problems are up for grabs. Part of why there’s so much unfounded hype is because of how many real advances have recently become possible. This period in history will never come again.
It’s also a rare time in history that an individual can make lots of progress. Most of us need to be a part of big groups to do anything worthwhile, in most fields. But in this case lone wolves often have the upper hand over established organizations.
For anyone experiencing depression right now, this video helped me immensely at one point in my life [0]. CBT has also changed my life; I highly recommend the book 'Feeling Good'[1].
The biggest problem I see in developer communication is what I call the "assumed context" problem.
As in, you talk/write to people as if they know all about your code, except the detail being discussed. In reality, they usually have much less detailed understanding, and you're making no sense to them.
I'm pretty sure this is related to people "on the spectrum" often having low "theory of mind" capabilities. People without that will just assume people know what they know, and proceed to fail at communicating with those who don't.
It also makes it easy to think of those who don't know what is obvious to you as idiots.
The workaround, if you want to communicate with the idiots surrounding you, is to start conversations by fact finding. The question "so how much do you know about the flurbigator system?" can help.
When people say they want career progression, and opportunities, what they mostly mean is they want more money. Unfortunately, most companies have fallen into the trap where if someone has a title of X they can only make up to Y, regardless of how good they are at their job or how long they've done it. When that happens then the name of the game is getting a promotion in order to keep making more money. That creates a perverse incentive, and the result is political bullshit that is typically misaligned with the company's interests which further drives away your high performers.
End the perverse incentives. Pay your people well if they're doing a good job, regardless of how long they've been doing the same job or what their title is. Reward seniority and loyalty. Suddenly, you'll find that employee retention goes through the roof, and you don't have to worry about hiring new people all the time.
My 4 year old son Michal died 11 years ago and I still grieve him every day. It is deep in my bones, an abscess. As this beautiful and heavy article describes, the act of grieving became an addiction to me. I kept "breaking beautiful things" in my mind because living with the ghost child instead of the living world kept his memory closer and my hands less shaky. He was an addiction, I had rituals I had to do (watch old videos, peruse old photos) every day. Without these things, I felt like I was betraying him. I fantasized about digging up his bones a lot. All a ruse, a cycle in my own mind, designed to soothe an addict haunted by his ghost child. A divorce and lots of personal writing and tears (and so many years) later, I am in a healthier place. But "grief is what love looks like when they're gone" is a simple and poignant way to put it: I will always be haunted, and I will always love the haunt, but I cannot be owned by him like I was for so many years. When he comes to haunt me, I welcome it. But unlike before, I don't smother him. Now I let him float away too.
Note that most of the performance improvements come from PGO, which is enabled with following environment variables. PGO is not enabled in .NET 6 by default, but will be in .NET 7 IIRC.
set DOTNET_ReadyToRun=0
set DOTNET_TieredPGO=1
set DOTNET_TC_QuickJitForLoops=1
Here are my own benchmarks from a CPU intensive application without any IO and already optimized for allocations. Application runs a task graph either serially or in parallel.
.NET 5
--------------------------
| Method | Mean |
|------------ |---------:|
| RunParallel | 473.4 us |
| Run | 513.5 us |
.NET 6
--------------------------
| Method | Mean |
|------------ |---------:|
| RunParallel | 452.5 us |
| Run | 499.8 us |
.NET 6 PGO
--------------------------
| Method | Mean |
|------------ |---------:|
| RunParallel | 381.8 us |
| Run | 412.2 us |
.NET 5 - .NET 6 -> ~5%
.NET 5 - .NET 6 PGO -> ~20%
Here is what I learned from micro-optimizing a .NET application:
- Use BenchmarkDotNet[0] for general measurements and Visual Studio profiler tools for detailed inspection. They help a lot.
- Memory allocations matter. Using capturing lambdas, LINQ, even foreach on interfaces introduce allocations and slows down the application. You can use ClrHeapAllocationAnalyzer[1] to find these hidden allocations.
- Using abstractions with interfaces and casting back to concrete types cause some overhead, though PGO will probably eliminate most of these.
- Use LINQ cautiously as its variants are mostly slower than explicit coding. E.g. .Any() vs .Count == 0
- Checking Logger.IsEnabled() before calling Logger.Debug() etc. helps a lot. You can even automate this with Fody [2], but it breaks Edit&Continue and possibly .NET Hot Reload too, so it may hinder your productivity.
At the company I currently work at we have "tech lead" (lead dev) as a role within a project: it is not in your function description. As you grow as a developer you will take on this role again-and-again in ever larger projects, it helps devs to grow.
I've copied the section below from our wiki, to show what we consider to be part of this role. I'm interested to hear what anyone thinks of it.
# What is expected of a lead developer?
* Technically in charge of the developer capacity within the project team
* Works in close cooperation with the PM and is crucial in technical meetings with client.
* Explains technical choices
* Recognizes when client wishes (tend to) go out of scope
* Facilitates efficient software development within the team
* Involves other parties when needed (i.e. ask designers for input when needed, etc.)
* Also develops prominent parts
* Understands the technical architecture
* Assesses (judges) any design-input for being complete and realistic (a check-list exists for this)
* Oversees software quality: has decent knowledge of all used technologies
* Knows best practices (i.e. w.r.t. security, documentation, testing, SEO)
* Verifies and then moves post-its from "verify" to "done" (except his own)
* Escalates to PM/AM whenever he/she foresees planning goals may not be met
* Can estimate the time it takes for his/her team to complete common tasks
* Possibly: technically architect the software at stake (for technically challenging projects we have an architect role)
* Possibly: supply time estimations for the project planning
* Chooses the tools and technologies used for the project (within the lines the architect has set)
* Allocate tasks over the team members, detailing the planning
* Takes the lead in translating requirements to tasks (Post-Its)
* Can deploy the project
* Knows the processes of our company
* Identify process improvements and speak them through with PMs/ AMs/ head of technology
* Applies the final checklist (and improves upon the list when possible)
I have a theory about why turf wars like this happens: the more successful and wealthy an entity, the greater opportunity there is for a manager to take wealth instead of make it. When you’re scrappy and broke, the only path to success is to make the company successful. When the company is rich and multitudinous, an individual can gain more from politics and turf wars rather than actually trying to push an already high enterprise value higher. The “maker:taker” opportunity ratio changes, and so does the type of personality the organization attracts.
It took us 18 months to make our first dollar and then another 10 months to hit $2k MRR. Now we're north of $800k ARR. (bootstrapped, 2 first-time founders)
Time frames of "three weeks" and "two months" are unrealistically quick, and might cause you to give up before you even give your startup a real chance.
Mayyyybe you can hit these milestones if:
- You've built a successful SaaS company before, and deeply understand product, sales, marketing, pricing, etc
- You start out with a validated product + market, so you have a high chance of hitting product market fit quickly
- You have a team and can work on building product + acquiring users simultaneously
But for a first-time solo-founder, this is just so unrealistic.
> Are many of the other languages you've used strongly typed? That's the thing that gives me pause - I feel like I rely on the compiler a lot in languages where it can do a lot for me, and that I'd be really frustrated managing a large project without it.
As someone who has been writing Elixir professionally for 4-ish years, and who is otherwise about as big of a proponent of static types as is possible, this is simultaneously my biggest critique of Elixir, and also a critique that has ended up being more theoretical than not. I wish that it were statically typed, but in practice that hasn't been slowing me down.
Part of the reason for that is that while Elixir is dynamically typed, I've found that it's possible to pretend it is a statically typed language if you squint just right. By that, I mean making judicious use of typespecs [0], dialyzer [1], Norm [2], and just generally constraining the way you write code to mirror the sorts of code that you'd write in a language that offers algebraic data-types, like Haskell. I've been meaning to put together a blog post on what I mean by this, because I often hear people talking about how unusable Dialyzer is, so I feel like my team is a rare example of a large production app that requires that Dialyzer typechecks on every build. This makes large-scale refactoring of our app almost (but not quite) as easy as it would be in Haskell.
The macro system in Elixir also means that it's possible to write libraries like typeclass [3], that offer compile-time guarantees (using compile-time property tests!) that your implementations correctly implement a given interface. I think that as the language evolves, we'll be seeing a lot more examples of macros that move runtime logic into the compilation step, to offer compile-time guarantees and safety. For example, a few weeks ago, I prototyped an experimental library in a few hours that added support for compile-time OCaml style parameterized-modules. [4]
Obviously, all of these techniques don't get you quite as far as proper static typing would (though the Whatsapp team is working on static types for Erlang! [5]), but the rest of the language and the ecosystem is just so well thought out, that I've been okay with that!
One of the biggest force multipliers in overcoming depression is accepting that you can modulate your condition by taking small, deliberate actions.
It's also one of the most difficult and delicate ideas to communicate to a depressed person. Depression notoriously clouds peoples' judgment and makes simple tasks seem impossible. Depression also encourages a lot of binary thinking, where people tend to give up because they can't achieve the optimal solution and can't imagine anything in between optimal and complete failure. And most importantly, depressed people almost never want to hear someone else telling them that they should do something to change their own condition. If you've ever been through a depressive episode, you'll understand how unpalatable this idea is if it's not delivered carefully. Be careful to not make depressed people feel even worse about their condition.
For example, I've known several depressed people who spiraled deeper into depression when they could no longer perform their regular 60 minute gym sessions multiple times per week. It took a while for them to accept that a 5-minute walk around the block is better than no exercise at all. From there, they could push to 10 minute walks on good days, then 20 minutes, then 30 minutes, and eventually work their way back up to gym visits. Taking those tiny steps is a great way to re-learn that you can accomplish things, and it's a great to way to see gradual progress in yourself.
It's the same with autoimmunity. Some researchers are obsessed with genetics. But it's mostly about self misclassification due to infections and dysbiosis. Luckily, some top journals have started accepting this, but it's still an uphill battle against the establishment:
I liked this article, though I think it missed the best part of Hacker News. To me, Hacker News can feel like walking through Dumbledore's office -- magical and mind-bending collections of incredible devices, ideas, and oddities.
Just yesterday someone posted a comment with links to UI design libraries that I've been subconsciously wishing for in my dreams (humaans, undraw.co), and I used it in a product demo. As a self-taught technologist, HN has exposed me to SICP, functional programming, and just yesterday someone posted a book about Data Structures and Algorithms that I started reading. Dang was quoted as describing HN as a "hall of mirrors" or "fractal tree."
The author's focus on the controversial political parts of HN seems to me like going to a music festival and commenting on the food trucks. Yes, it's part of the experience, but that's not why people go and not what makes it magical.
Communicating the beauty of unfamiliar technical topics to a lay reader is much harder than politics, but the New Yorker has done well at that elsewhere (I like the Sanjay and Jeff profile). Moderation is an interesting topic in its own right, though, especially in the age of the IRA and meme-warfare.
> There are times during the development of any project where one might be tempted to hack around an issue, or commit the ugly code that seems to work. These are the rough edges that inheritors of a codebase use as evidence that a blank slate would be preferable.
Yes, one thing I've learned is to never underestimate the power of inertia in a codebase. When adding functionality, 99% of developers will go for the path of least resistance, which is mimicking whatever patterns already exist. To loop back to the article, this is often due to lack of full understanding; the default assumption is that because something is written in a certain way, that it's the best way. This isn't true; it may not even be the correct way! But copying what already exists has an element of safety built into it, without needing to spend the effort to deeply understand existing code (which tends to be developers' least favorite activity).
So if you put in an ugly hack, or have a code structure which doesn't make sense, expect that to persist for years, or decades.