Yeah I used to have a massive spreadsheet tracking the entirety of household finances. I was worried that no one would know where the money was if I suddenly died, so I started a monthly finance 1:1 with my spouse. Even wrote an "upon death or incapacitation" playbook for her.
The second session was just her saying WTF I can't keep track of the location, ownership and tax benefits of 40 accounts!
I've since closed 3/4 of all accounts because of that.
The killer for me was working out how much time I was spending playing Excel Warrior and how much it was “making” me and realizing that I was working in my free time for Pennie’s.
that is what keeps me from getting into all this detailed finance management or worse trading, likewise any other side business that could earn some money but just isn't the kind of work i want to do.
making a budget is useful, as is tracking your expenses, but that's about it for me.
While I agree on the withdrawal symptoms, the main differentiating point for me is that drinking coffee doesn't waste time. Marijuana consumption is one of the most unproductive things to do for leisure. I don't do alcohol for the same reason, it's a massive waste of time. Both render the consumer functionally useless for hours, and, if you're older, assures that the next day will be extremely unpleasant.
There's also a big difference on a social level. Have you ever had a pothead as a roommate? The entire house smells like a garbage dump 24/7. Whereas freshly ground coffee actually smells good. Coffee addicts only bothered me with their unwashed V60s lying around in the sink.
With respect, this sounds like a kids show depiction. It's not like an opiate, nor anything like being drunk. People use it while working - coders, writers, artists, etc. in the day time, often along with coffee. I think a lot of people get this wrong about weed, because "functionally useless" is not at all how I would describe it. Some of your favorite music, video games, even coding libraries were created by stoners!
Also when you say coffee smells good and cannabis doesn't - highly subjective right? I love coffee, but some really high quality coffee smells like s*t haha (literally). There are some fruity, piney, lemony, and floral scents from fresh cannabis, just like there is a nice aroma from fresh coffee. In both cases you're talking about a flowering plant, with highly subjective smells and varying terpenoid profiles. However, note that the terepenes "pinene" "limonene" etc. in cannabis are the exact same plant terpenoids in pine trees, lemons, etc. so if you like the smell of pine trees, lemon, mangoes, roses, and other highly floral scents, you will likely also at least appreciate the smell of cannabis.
Liking the smell of pine does not mean I want the smell of a pine forest fire in my house all day long. You don't see caffeine addicts rolling up coffee grounds to set fire to it, do you?
There's nothing subjective about not wanting smoke in my lungs. If someone wants to get pot buzzed, go eat an edible and waste a day of productivity for all I care. Smoking the entire house, and costing me my deposit while justifying it with "George Carlin wrote jokes on weed" is peak pothead narcissism that makes me want to have it permanently banned.
The Tesla cars are the only cars I've ever driven that can simultaneously provide one with the very best, and yet absolute dog shit driving experience. It's a weird car that I honestly don't understand. Especially when people talk about the software being the best on the market. I don't recall the last time I cared about car software more than being able to use the turn signals properly. Great acceleration though.
India ban of rice export is partly because Thailand and nearby countries are also expected to have a bad crop this year which will put pressure on Indian rice prices. The first year probably should not be a problem but if it carries on to the next year then it could be bad in term of prices.
Welcome to the group, we meet alternate Thursdays and worry the rest of the time. For most of us that's as far as at goes. Some of us get all hyperfixated and might save the world, though.
I can confirm this is common. But after sterilizing the bottle or washing the bottle, you don't give that water to the child. One usually just cleans using the microwave, rinse it out, then you add water from another source that hasn't been in the microwave in a plastic container.
Well yes, but whatever milk/water you serve in it right afterwards will still taste and smell of burnt plastic. I take it as something inevitable because no one's going to be giving a glass milk bottle to an infant.
Maybe I should dump every single child plastic drink/dinnerware for 18/10 stainless steel.
To be fair, unless you're building some low level infrastructural systems, coding is the easiest part, and code is cheap.
Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.
If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part.
Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.
There's a misunderstanding here due to context. Someone working in a startup (been there) will find it difficult to understand just now much communications are required to get anything done in a large MNC. Out of necessity, people who have pushed enough code to understand the systems have to step up to do the comms instead of being siloed. I had many a time freaked out some other team because the phrasing of my email made them think we're going to dump more work on them. This is the actual difficult part about engineering at scale: Getting everyone on the right page.
You can opt to keep coding, but it won't get you far in your career. Does this mean the communications have more value than actual implementation? It depends. Again, this value differs at different company sizes.
I just got the chance to code again last month, and I've already completed 5 features (code reviewed) that the juniors couldn't complete in a year. I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot.
I stand by my statement. Code is easy and code is cheap. One day you'll understand.
It's not as if there are only startups and MNC, though.
My current company is very small, we're less than 15 developers. But it's a multi-tenancy B2B software that has, in some form or another, existed for 15 years, uses tons of outdated tech, where most of the original authors have long left the company, and so on. Getting up to speed with the code base and changing stuff is slow, but not because of organisational red tape - it's because it's really difficult to predict the impact of changes.
> I stand by my statement. Code is easy and code is cheap. One day you'll understand.
You don't have people under you that can complete in a year what you can complete in a month, and you're still insisting that anyone and their cat can code?
> I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot.
I might phrase this a bit differently, but I think it’s getting at my thoughts as well.
I work with developers who would destroy me in a race to implement various search algorithms, or whatever discrete metric of coding prowess you want.
What they struggle with is:
- Efficiently getting other teams to answer their blocking questions in a way that makes the other team happy to work with them.
- Understanding the existing features of our fairly complex stack.
- Judging when to ask for help, and who to go to about a particular problem.
- Identifying dead ends quickly, and pivoting to alternative solutions at the first sign of trouble.
- Incorrect assumptions about the company’s priorities, and how the priorities can help shape the request.
I end up in a lot of meetings, but I also occasionally (a couple times a year on average,) take a few weeks and implement a business goal that a team has been stuck at for months/years.
Read: I'm (ironically) not good enough at communication to explain my point, so I'll just say a grandiose sentence to convince you I'm right without giving you any useful information.
Then you have quite limited experience (or you're just going for some snark).
Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects.
Out of interest, just who do you think should be doing the high level architecture?
> Out of interest, just who do you think should be doing the high level architecture?
People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
I often see the argument that people who write the code should do the architecture as well. Maybe on a small development effort it can give better alignment.
When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen.
However, this does not mean that the architects are idiots, although that is of course possible!
At the company I work for, senior engineers are usually responsible for writing RFCs and getting the involved/dependent parties in the discussion, staff engineers chime in with architectural details the seniors might have missed due to a hyper-localised view of the issue/proposal. This feeds back into seniors understanding of the whole/higher-level architecture, which it's then used to adapt the proposals with the architectural decisions/requirements/constraints.
High-level architecture at scale demands a level of knowledge that engineers from a specific team might not have, not due to incompetence but because the scope of the team is bounded and the context is very local, at large enough orgs it's not possible even for senior engineers to keep track of all the weird interactions systems have at a higher level, you need someone whose job is to look at a higher level and validate cohesiveness, someone that knows about other similar work being done across other orgs to see points of cross-pollination, etc.
Honestly I can't see how I could depend only on myself and other senior engineers in my team to validate architectures that span cross-org, it'd be exhausting to shift my context all the way up and down architectural layers for every single RFC I write.
Domain experts, financial or business specialists.
I've never seen a competent software architect. They make wild statements, draw some trivial diagrams with impressive sounding words.
Then some diligent programmer discovers that none of it works, silently creates the real architecture. Then the "architect" takes credit for the result.
The days of Internet RFCs that are carefully written are over. We are in the age of agile self-promotion and B.S. (this also applies to foreign policy, with the same results).
Having senior dev / "architect" focusing on higher level / abstract design and working with junior dev to code it and get it up and running is a very common pattern in big company (especially not tech-first company). And it does work.
In truth, it is more a ad personam argument. You are not contributing anything substantial to the debate, you are just attacking dumpster_fire with no other argument than "in my experience".
The only data you provide is "your experience" which is of little value here considering we don't know the extent of it nor its relevance. If anything, the way you express your opinion so strongly, one would hesitate to think that you have any experience in a big corporation with several teams working on different product and/or part of the same product. The context in which having senior dev focus less on coding and more on reviews, documentation and design is common place.
We have the data that dumpster_fire thinks anyone can do coding, which tells us he's not well versed with it.
From there, by experience, people who aren't good juniors aren't good seniors. Good juniors might never become good seniors, but bad juniors won't be good seniors.
I don't see what my life history has to do with anything, when we have all the information right here :)
What data? I never said anyone can do coding. My spouse sure can't. Code is the easiest part of the job in my company where almost everyone is a genius (sans me). But few enjoy (nor do well with) syncing project goals with other teams. Someone has to do the dirty work while getting dissed by juniors for lack of code. I'm not sure if this experience applies to where you're working at so YMMV.
But I must admit that this is karma. For I have had an almost identical take as you more than a decade ago. Feels like I'm looking in a mirror.
Context is key here, but as a thought experiment- the most profitable businesses can hire with effectively no limit if they choose. FAANG isn't a great proxy for that but it'll do - assume their hiring bar is "can produce excellent code". Then what? Do you just allow everyone to heads down code? Principals and staff engineers rarely contribute directly to features because in their org context, with their expected level of staff - code is cheap and easy. Orchestrating decision making is very hard, and aligning technical to product outcomes is hard. How often are these businesses with huge budgets routinely criticised for poor releases? Yet their overall value remains enormous, because their cores are money printers.
Being an expert in the domain of writing code is relatively easy. Being a domain expert of your businesses value and the tradeoffs its making is very difficult. Just because people like the writing code part of the job doesn't make it the end game for the most valuable skillset.
Let me explain. Coding is the easiest because it's the most fun I get from my job. I don't have to talk to most people, I can have my alone time just writing code, cleaning it up, making it beautiful and lean, refactor as I like, whine about the unit tests taking more time than coding, and go home feeling like I've accomplished a lot. It's easy because that's all I have to focus on. Give it two weeks of junior devs telling me my coding style is outdated, and I've already adapted to the new meta.
System design at scale? Just trying to convince a separate team to work with us is a nightmare that I get insomnia from.
Coding is the easiest part of my job. FWIW I was just like you when I was a junior dev. Wondering why senior devs and engineering directors can't code. Now I know they can, but their time is better used to negotiate projects so that the junior devs can have their fun. Then I have to take time out to mentor junior devs on how to talk to people without being condescending, because that gets absolutely nothing accomplished in a large company.
Maybe the directors at your particular company can code. But a lot of them really don't. They don't understand the technical aspects of the problem and this results in bad decisions.
I've had someone who drives expensive cars tell me to change a simple line based streaming text format to XML to "make networking more unified across the company projects". He suggested to add a 120 KLOC XML library that does memory allocations right and left to our <10K line embedded project with soft real time requirements.
To set the level of experience, that same person claimed in the same meeting that UDP wouldn't lose packets on a local connection. And when I didn't obey he played a power game.
The better a product is factored, the more all aspects of development are interdependent. Creating isolated work packages leads to a badly factored product with lots of duplication, creating bloat and bugs and preventing important features and optimizations. That's why sometimes, small teams of really smart hard working guys can be extremely productive in comparison.
That said, team size can be increased, while smartness and hard workingness of the team can generally not be increased, and a lot of tasks can also just be grinded through, or they need to be grinded through because there is no realistic way to avoid it.
> Give it two weeks of junior devs telling me my coding style is outdated, and I've already adapted to the new meta.
Brilliant! I always say that I know how to code, I just need time to figure out how you code so I can match the style. "Adapt to the new meta" is a great way to put it :)
When I'm coding these days I feel guilty, like I'm wasting my time doing something fun when I should be doing real work!
At my former company, a 60 person startup, my CTO - a 55 year old guy - could code, design AWS architecture, do data analytics using Redshift (an OLAP database) and Athena (Apache Presto) and would often do POCs to research an idea and throw it over to wall to me to make it production ready.
It was a godsend when I was already overloaded with work and technology research. I was New when it came to cloud at the time.
On the other hand, his value add to the company and even to me wasn’t that he could code and design. He was a force multiplier by talking technical to our customers (B2B), mentoring, working with the owners, setting priorities based on the business needs etc.
I’ve had plenty of managers who could code and would rather spend fine coding than doing their job as a manager - career development, navigating through the political landscape, protecting their team from organizational bullshit and being “strategic”.
Coding is easy. At my current job in consulting, a hands on coding project is much easier than my more strategic consulting projects where I’m working with multiple teams, dealing with CTOs, CFOs, architecture review boards, dealing with fiefdoms where the “DevOps” team doesn’t want to give the developers the leeway they need to do their jobs efficiently and where tte developers want Admin access to everything and make a mess, etc.
That's a really bad faith take of that comment. I'd translate it as "in a place where most people are experienced programmers, communication becomes the main bottleneck."
Unfortunately I don't possess long range telepathic abilities, like you seem to have.
Ironically, it seems that even if your interpretation (or mind reading) is correct… we have someone that should be facilitating communication that is clearly not good at communicating what they are thinking.
Isn't what you described as The Slog essentially just SMEs? That's not so bad. Perpetual meteoric growth for everyone is not healthy on a macro level. Couple of friends of mine are in what you describe as the worst outcome, yet they can buy houses and put their kids through schools (outside the US).
There's a middle layer of B2B that props up the economy in a more fragmented manner, and I don't think they should be dunked on.
It’s fine if that’s your expectation. It’s fine if you’re bootstrapping and comfortable with your level of success. It’s hard if you thought you were building a rocket ship, raised money selling the vision of the rocket ship, and benchmark your success versus others who built rocket ships.
It could be a pretty good SME for the founders, but there are a few possible issues.
1. You have investors who expect returns and don't want (or can't have) dividends.
2. You have employees with stock options that want them to become something.
3. Your company could be set up as a C-Corp, if your intention is to have a stable business and earn dividends you'd rather have it as an LLC with founders as members.
Basically, issues happen when you take VC money but don't end up going the growth startup path. Buffer had the same problem, but they managed to earn enough money to buy their investors out.
The second session was just her saying WTF I can't keep track of the location, ownership and tax benefits of 40 accounts!
I've since closed 3/4 of all accounts because of that.