What's more curious is why is it becoming popular nowadays. The internet, of course, factors into it. But ideas don't stick only through dissemination. The adopters of the idea need to be able to relate to the idea to some degree.
921 karma · joined September 12, 2019
On volcano, I could talk about one particular volcano here, mount merapi. It regularly coughed some lava, not too big to cause countrywide panic, enough to fertilize the land around.
- PHP's capability is limited in a sense that its main use case is akin to a template engine rather than a full fletched executable. This puts a lot of limit in PHP
- TS steps up JS' game. Like what other have said, TS brings the hassle of maintaining complex codebase down quite a lot.
- NodeJS is a stepping stone for many frontend developers to learn backend because of the same language used.
- JS' syntax and capabilities, while having inherent unavoidable footguns, allow expressive code (I might be partial on this, the last time I used php is a long time ago)
Edit: formatting
I might have picked the wrong word "measurable". It's better to stay away from ultra-narrow measurement. "When a measure becomes a target, it ceases to be a good measure" Instead, put the phenomenon in their head. Make it their responsibility. Point out the impact of readability to the team velocity.
Or maybe, examine if the introduced complexity is actually incidental and not essential. IF it is essential, it makes more sense to upskill the rest of the team. Hold sharing session to hear everyone's thought. Hear what the smart guy thought about the code. Sometimes, what someone need to unlock a heap of more horse power forever is just a little nudge that makes them click. Create team conventions for making things easier for everyone, e.g. indirection through naming in which you need to pay a bit in performance.
> minimize the amount of brainpower I needed to understand my code
> weighing it against the larger system.
If you haven't try converting these items into something more measurable, and put these problems in front of the smart engineer and let these be their problem?
Sort of delegating these stuffs as their problem too instead of taking it all your own.
One time there is a person who wants a system rewritten, because of some perceived complexity. The original builders who built the system from the ground up is still actively maintaining it, but there is no attempt to understand whether the perceived complexity is incidental or essential, which in fact most of them are the latter. Some people just want things to fit their world.
But, on the bright side, there are people who just don't know history, but they would be happy to learn. There's a hopeful number of those people!
In contrast, my little brother was enrolled to drum after he developed interest, in jazz. He has the friends who are passionate with the same kind of music. He built several bands. Not only the music itself, he developed love for analogs, obsessed with building instruments and speakers.
I guess the timing of interest development relative to the push to the direction, and having the right people to reinforce your passion is imperative to the optimal development of "click" to music.
But well, usually dynamicizing statically-known types yields premature abstraction
My company is building app with quite a set of complex features and structure (e.g. stateful integration with game consoles, background custom upload protocol, varying lifetime of modules, etc).
- The state management we always come back to is closure-based objects.
- Styled as agents, rather than passive storage (e.g. redux store-like construct). Thus providing separation of concern both in type definitions and code execution scheduling (can't find better words for these :'))
- In house event utility is used by the agents to communicate outwards.
- Combine with useEffect, useState, useMemo, and our in-house event utility to "escape" React's lifecycle by default and selectively subscribe to events, thus avoiding unnecessary-rerenders problems.
- Designed to abstract its domain and expose its internal data via methods.
- Optionally be designed to allow both code reuse and object reuse. Allowing devs to share or to not share states. Common use case for object reuse is agents acting as background-service propagated via React Context. It works really well with React Context.
- Optionally self-managing via buffers and async loop. The buffer is not exposed to its consumer directly, and the async loop works on the buffer.
- Can be useful for dependency injections too.
- Well isolated and optionally injectable so that you can unit-test against it without import mocks.
A caveat, this pattern isn't as usable when written with pure JavaScript. We relies heavily TS on FP patterns supported by fp-ts and io-ts as well as IDE's auto-complete and jsdoc to unload a whole stuff off our mind.
We've sometimes evaluated common state management solution and often found them requiring us to remember more things, but it doesn't yield valuable abstraction. In fact, most state management is abstracting the wrong thing.
Location: Indonesia (with high possibility to move to Stockholm, Sweden next January)
Remote: Yes
Willing to relocate: No
Technologies: Rust, TypeScript, React, NodeJS, Electron, SQL, NoSQL, Docker, Git
Website: https://valand.dev
Résumé/CV: https://drive.google.com/file/d/1p0iGur8l5pZUcQud34hiMBcG3_zRoqAZ/view
Email: kelerchian@gmail.com
Contributing as a technical lead to 3 projects that are now running in production.
Have sufficient experience experimenting through unknown territories, building abstraction for the team, and encouraging people to do the same.
Primary interest and expertise = system design and engineering, information architecture, product design, knowledge organization.
Then there's the hypergrowth phase. It's good for the money. But the culture downgrades for both the communication, the engineering, the product. People complain a lot but don't slightly ever make a plan to fix things.
It is tiring to be one of the few who still care.
You are losing and with that state of mind you might be attempted to keep losing, but I don't think you want this to continue, do you?
The first thing is to start winning. Realize that winners keep winning and you are going to be one. Create small goals! Inside and outside work. Move! Do 5 push ups, 10, 15! Doodle simple toons, sing some music! Write a simple game on a simple framework! Sleep on time! Wake up early!
Focus on things you can control. The corporate environment, you cannot control, at least for now. Treat them like a child demanding things to their skewed worldview.
On your firing, you're looking at the worst case. There's a chance to improve, there's also a chance to explore new fields.
If you intend to keep the job, tell to your manager that you are dealing with your problems and your're getting more and more succesful. Fake it till you make it, but stay on the course so you can make good with the job.
I presume low code/no code comes from the simplest notion of programming language, which is a medium between human and machine. And the easier it is to read and write means the "better" it is. Therefore pitching it to a non-technical or even semi-technical people is as simple as teaching people to write code at surface level.
However what people don't understand deeply is that any language is a set of symbols and rules requiring a certain amount of cognitive space and a certain time to absorb it. The more ambiguous the symbols are, the closer the growth of the number of the rules to exponential. This is a fundamental point that happens in real-life but is rarely understood, moreover to programmers, surprisingly.
I believe a proper low-code/no-code should have natural language processing capability and understanding context, not just providing syntactical aliases.
2. This depends on how much you want to have control over your core business technicalities. Open source works wonders if we're dealing with complex standards, but not when the subject needs to change often.
4. Can't argue with that. Go for the extreme route of business object modelling the functional way.
5. Or add analytics when ethical!
This sentence strikes me at my trauma center.
The company I'm in is at the critical phase of startup. 4 years down the road of hypergrowth, the knowledge gap and quality gap is apparent. But then I realize that corners are cut because of a lack of expert in the area whose authority is recognized.
Most experts and brilliant minds have the same idea about the corner cutting. When foundations are designed to be reliable, velocity may jump exponentially, they know. Reliable isolation, version gating, and enablement over service is how they should move, they know. Product design and physical constraint has at least one coupling string, they know.
But these people aren't given the authority, not invited into the room where the decisions are made. In the end, those who bring the immediate money prevail over those who bring mere potential of 10x more money.
As the article said, hire the best engineers. But what the article miss is to hire the best engineers who is invested, can thrive in the politics of startups and use the attained power to bring everyone to success.
Such as paying time in exchange for reliability (e.g. TCP/IP, retry and backoff), disclaimer for unreliable behavior and law-related issues, version gating for file formats/protocols, redundant storages, and killswitches for going rogue-prone machineries.
It is an ongoing thing, but I found friends with the same values and we are trying to change the environment that cause the burnouts. At the same time I have to convince myself that coding and managing is not the actual root cause of the burnout.
Having friends who share the same sentiments helps. But the most important thing was to identify what exactly is the root cause and bash it.
Talking about it to your manager will help alot if your manager cares. In my case, my manager talked and get the head of department hire a veteran that becomes my mentor and take over some of my workload.
Hiring properly actually helps! It lets good people in. Once onboarded, they alleviate your burdens so you could think of strategies that to change the environment so it's better for everybody. This changed my mind about hiring people, since I previously had a bad experience with hiring when my company was in a hypergrowth phase.
In my case the cause was the classic pm-does-not-know-technical-stuffs-yet-plan-everything-ahead-behind-closed-door-and-say-the-final-decision. Fixed deadline, immature product desig that doesnt account for technical limitations. So often either we had to: 1.) Propose a fix now and add more to our plate so we crunch, or 2.) Not propose a fix and risk ourselves getting woken up in the future.
We kind of had to learn a bit of PM-ing so we "understand their language" and have the ability to persuade them into understanding what happens on the other side and making changes that beneficial for the whole team.
Things are changing slowly. Processes changes within the orgs for the better. Some external influences still could reverse the progress. But a celebration for small steps is in order! Party with the people you care and cares about you.
At least that is how your user expected your app to be.
There are no strict rule over your system design other than "whatever makes sense the most"
Data modelling and managing complexity (or I prefer to say knowledge organization) is a prerequisites for every software program ever.
I'd add one more: System design.
Basically dealing with many asynchronous moving parts, managing entities' lifetime, separating and categorizing domain/data, and understanding what-is-important-to-whom. It is a knowledge that's applicable whether you are programming a kernel scheduler or managing people and projects
Bad manager asks questions, but then discard the part that is not important to them, even though the team needs the manager to understand it.
Good manager asks questions and understand (at least try to) if this is important for the team, for the project, and for the company. When they ask about deadlines and estimate, they ask why, and they try to deduct, and they remember. Good manager that works in the business selling technical product attempt to understand the technical part of the product instead of blindly "delegating" it and demanding things done.
Good manager tries to improve all aspect in the team. The process efficiency. The communication blockers.
I've seen first hand a manager, having no technical background, getting capable of reading C++ code over time to help the struggling team, and yet does not realize to have been so technical. Kind of having an impostor syndrome. Because they care so much.
I've also seen first hand a manager that only cares about deadlines and presenting good stuff upwards. They don't care about details unless asked by their superior. And once asked for details, they act like messenger owls and echo servers.
- it is either looking to get sustainable as early as possible,
- or, if not, it is a research into the unknown (e.g. quantum computing, different purpose of db, new kind of AI, space exploration, green earth initiatives, even the early phases of blockchain)
Another points would be if the founders have the motivation to give back rather than take as much profit. My current company's founder have a dream to make an incubator for aspiring game makers, for example.
> I have never worked in an early stage startup.
The young company I have been in is when it was 1-year old. Founders are not looking for a mere "engineer", but one that can drive the team "above and beyond" style, because it is important for a small company. But, it is very difficult to see in people. The common mistake of many is to look for their own virtues in other people, which pretty much limits the other set of people not having the same virtue. E.g. Founders that focus on verbal communication and sales filter out people that cannot speak fluently, even though those are excellent product and engineering people.
The worst thing is to be refused without knowing what's wrong so you're kept wondering why. Is it geographical reason? Is it national border reason? Legal reason? Culture fit? Personality fit?
Another worst thing is to be denied without any tests. Nowadays, I'd pick difficult and time consuming technical tests over being denied by technical merits due to incomplete CVs
Same here. Med to high pitch does the same effect as words for me. But undecipherable words or ambients does not have the same paralyzing effect as words, things like metal growl, mumble rap, or ambient acapella. My goto music would be extreme polymetric metal music with dark tone (bright guitar tone doesn't work for me. Check out my fav band Meshuggah), noir jazz (jazz which accompany noir detective/mystery film), or muted song whose mid-to-high pitched instruments arent quite prominent.
And then there is a friend of mine who can program while listening to podcast. A mad lad he is I say.
The principle concerns the duplication of knowledge, not code.
Author's reference to "accidental duplication" is caused by two similar code that represents different code that is when joined becomes the code that is ambiguous in meaning.