> However, at some point it seems that everyone at my stage is moving into management or higher level positions doing project management, meetings, architectural discussions
This impression is mostly generated by your head, to be more specific - by the social pressure to "make a career" and to regard technical skills as inferior to management skills. I don't think it's real, I saw many old people working as programmers, and there will be many more because there are more programmers among the current 20-30 year-olds, compared to the older generations. Also there's simply many more technical jobs available and there won't be enough management positions available to allow the switch for everyone. And the pandemic looks also like a quite big factor in reducing the number of management jobs (it looks like you often can work as usual without all the managers...).
The problem I experienced multiple times in 50-200 KLOC projects is not the time needed to import the modules, but the memory consumption caused by the imports. Moving some imports from top-level module statements to inner functions' code could improve the memory consumption several times, e.g. from 250MB per process to 80MB per process.
That's very nice code and Python is non-functional. I love its generators.
That's my version to make it more "functional":
from itertools import cycle, islice
from operator import add
fizz = cycle(['', '', 'Fizz'])
buzz = cycle(['', '', '', '', 'Buzz'])
strings = map(add, fizz, buzz)
strings_or_nos = (s or i for i, s in enumerate(strings, start=1))
print(list(islice(strings_or_nos, 100)))
Yes, this also seems weird to me. And I think it might be a cultural thing, I noticed that in Europe renting dedicated servers is far more popular than in the US.
IDK where you get the 'wages are a lot lower in Europe' thing. There are lower cost and higher cost places, but people are expensive and talent is mobile.
I don’t know, in the Bay Area 150k is entry level and big companies pay 250k or much higher to senior engineers. Whenever I hear about pay in Europe it’s a fraction of that. It may be worth it for a different lifestyle, I’m not making that argument. Regardless, from the company POV it must lead to different choices about buy vs. build.
Bay area or NYC sure, that's like being in London, but what about the Midwest, or any of the places where you can easily set up an IT shop without paying a premium for space?
- Get your own bedroom.
- 30 minute commute.
- Not everyone you meet will be in tech.
- You'll be rich compared to everyone else in town.
- Partner with local academic institutions to offer recognized research projects and training. 20% time or 3 month project stints etc. Adjunct professor ships for people with an existing research record.
- Throw in X free flights to east/west coast, home town etc.
there’s 30 minute commutes in san diego, la and sf if you live in the right areas. what about weather? cali has really nice weather. schools / doctoral candidates / etc are basically useless in the real world. if i’m making enough money the free flights are useless. nothing you said here makes me want to move to the middle of the US. exactly what i’m looking at is the lack of opportunity. say i decide to move for some job and hate it. now what? pick up the family and move again?
I ride a bicycle daily and vape e-cigs. If anything I notice an increased performance immediately after vaping, I feel like I'm less tired and have more energy.
Overall this is an interesting topic because contrary to popular opinion many athletes use nicotine and find that it increases their performance: Nicotine [...] use is widespread amongst professional team/strength sports (e.g. American football, ice hockey, wrestling, bobsleigh, gymnastics, rugby, skiing) whereby active consumption of nicotine and nicotine-containing substances in-competition occurs in approximately 25–50% of such athletes [1].
The meta-analysis [1] found that two studies observed an ergogenic effect, one an ergolytic with the remaining seven reporting no change.
I cycle daily and vape. I feel when I vape more, my performance on a bicycle deteriorates very noticeably. My effective lung volume is noticeably lower.
Those athletes have trained for years and have a heart that is well conditioned with strength and cardio. A normal person who is moderately physically active is nowhere near their fitness level. That’s why nicotine is a dangerous thing to gamble with. You might be fine, or you might have afib/vfib that leads to an MI. Rather avoid the risk. Plenty of more potent PEDs out there that don’t cause adverse cardiac events.
But even for fully on-site teams the preferred format of a "knowledge base" is digital (wiki, Google Docs, etc.), because it's something that lasts, can be improved over time and is always accessible. And having the discussions stored digitally (Github issues, emails) is also usually preferred because it's "asynchronous" and it's something that can be looked up in the future.
So on-site teams also use Wikis/issue trackers/emails a lot. The difference is that instead of a face-to-face chat remote teams have to use Slack. Which is also largely used in on-site teams... So my point is that some of the modern IT offices already resemble a "co-working" space because all the tools are already digital, and all meaningful knowledge sharing already happens in the digital space.
You must be more active when working remotely wrt. seeking social interactions. When working on-site, you get some of the interactions for free. When working remotely, you must actively organize them by yourself. I know people who get MORE social interactions from working remotely because they have more energy/time for things like meeting with friends, clubs meetings etc.
Generally my feeling is somehow similar to the one expressed in the blog post, ie. that DSLs don't work for non-technical people. If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. And regular programming languages are better tools for the ones with the abilities.
> If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities.
I'd disagree with this characterization. Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply).
It doesn't follow that someone who understands the concepts in the DSL must also understand the superset of all regular programming concepts. Hell, most Java coders couldn't even write a memory manager from scratch!
Which is exactly where their power comes from. Because each time you shrink the required knowledge to do work, you broaden the pool of people who can perform that work.
> SQL is used widely, but it does not work that well for people who are not programmers.
Is the key phrase that shows the author has no idea what they're talking about.
I can count 20 analysts, off the top of my head, that I personally interact with on a weekly basis at work that disprove the point.
They have incredibly deep knowledge of their particular datasets. They know more than enough SQL to produce efficient queries for their needs. And they wouldn't understand exception chaining if it bit them in the ass. But they still run their part of the business better than I would.
Author is making an "anything shy of perfection isn't worth doing" claim, which misses the forest for the trees. The objective of programming (DSL or otherwise) is to get work done.
Not to be ideologically perfect.
Which is one reason Python is wildly successful, despite all its Oops design bits.
> (In author's defense of DSLs) There are AWK, RSpec, EJS, Emacs Lisp, bash scripts and a lot of others that are cool because their domains are steady and they are used by professionals.
The pompous twit... so data retrieval isn't a steady domain and business analysts aren't professionals?
> Which is exactly where their power comes from. Because each time you shrink the required knowledge to do work, you broaden the pool of people who can perform that work.
That's an excellent point.
It seems the same concept could also apply to broadening the scope of complexity that an individual could handle. The fewer things that the user needs to have in mind, the more mental space is freed up for other things, like domain complexity.
> Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply).
I agree, I wrote this small example on using DSL for E2E testing, where you abstract away a lot of asynchronous calls, headless browser specifics and other low level concepts to expose a simple API so domain experts can help you to write tests https://github.com/davps/tic-tac-toe/blob/master/src/App.tes...
