Mekkanox

As a long-time MUI user myself, I had the same "revelation" about Tailwind recently. Before MUI, I worked at a couple startups where we came up with our CSS franken-framework with homegrown utility classes.

It's just easier to do fast proto-typing with various Tailwind classes, and then refactor common sets of HTML tags with tailwind classes, they become reusable React (or Svelte) components.

Indeed. Anecdote: Several years ago I worked on a U.S. GOSS (Government Open-Source Software) project that was a web app that allowed different apps running on different domains to function as "widgets" and allowed cross-domain communication between these apps in a drag-and-drop window environment in the browser. The intention was small apps could be composed into larger apps by allowing them to communicate with each other in this environment.

It supported multiple browsers, including IE7 in as late as summer 2014, because end-users in the U.S. Navy had machines that only had IE7. Countless man-hours (and U.S. taxpayer dollars) were spent to ensure all features worked in IE7, including drag-and-drop and responsive UI.

That project was the single biggest driver for me to get the hell out of the government contracting world and into the "truly" private sector. At least at a startup I can say more or less "if it works in Chrome, it works."

That's definitely a viable option for biking around a city that doesn't have favorable spring or summer weather. Can you store your bike inside instead of locking it up on the street? I imagine an e-bike would be at greater risk of theft than a regular bike. That might be an issue for folks who commute by bike but have to lock it up outside.

Regarding commuting via bicycle: it's not necessarily a problem with traffic, as more with weather. Also it's wrong to compare a single city, Amsterdam, with a bunch of American cities because of drastically different weather patterns in those cities.

Amsterdam has average temps (in F) from the mid 30's to the mid 60's[0]. That's prime bike weather. That's pretty much in line with San Francisco, which is a good city for biking. Even Manhattan and Brooklyn have reasonably overall pleasant weather for biking.

But compare SF to somewhere like Washington, DC, or Austin, TX. For 3-4 months of the year, DC feels like a swamp. Same with Austin. It's much more preferable to use public transit or drive than bike in that weather.

[0]http://www.holiday-weather.com/amsterdam/averages/

Washington, DC? I think though that in the surrounding metro area, a SFH costs more on average than in Chicago.

I think a majority of the motor vehicles are taxis, buses, private car services, and what does the most damage per vehicle - commercial vehicles. Box trucks take a much greater toll on roads than a bunch of average passenger cars.

For at least a few years now, even conventional "slushbox" automatics get better mileage than a manual transmission when in the same car.

Lower maintenance costs are usually mentioned as an advantage of manual over automatic, but slushboxes have been around for quite a while now. With routine maintenance and average use (meaning no launch control usage or burnouts), both types will last forever.

It's not awkward, and it's totally your prerogative for telling a recruiter for that. If they say "well I won't work with you if you won't disclose that info", then I'd say "thanks for your time, good luck in your search." Nowadays there's always a dozen other recruiters who'd be willing to have a phone call with a developer who's actively looking. Obviously, YMMV.

As a rule, I don't tell third-parties (recruiters, etc) my current or former compensation. I ask what range the company is aiming for, and whether I'm interested or not. I think compensation is something to be discussed only between the candidate and the company.

Anecdotal story: I once was lowballed without my knowledge going into an interview set up by a third-party recruiter, contracted out by the company. They were very excited to get me in - turns out the recruiter gave the company a number that was 25% less my current salary. The company wouldn't be able to meet anywhere near my actual current salary, but the recruiter wanted to get a butt in the seat by any means.

From now on, I keep that info private until I choose to disclose it.

It was a combination of:

1) The language was created by a researcher (Guido Van Rossum) at a research facility in the Netherlands [1]

2) Network effect - as more machine learning researchers and engineers in academia used it, the need for a language that could integrate with FORTRAN with similar performance came about, which lead to NumPy, SciPy, etc.

3) The language itself is pretty simple to grasp. There's multiple ways in Ruby itself to do something, while in Python there's at most one way to do something. Anecdotal - a lot of researchers I've worked with care more about the usability and ease of adoption of a language, compared to the expressivity.

[1] https://en.wikipedia.org/wiki/Python_(programming_language)#...

Just a quick note for folks interesting in joining 18F: it may be a much more fun place to work as engineer in the government, but it's still the government.

You start off with 2 weeks of paid leave accrued per year, and it'll be at least 15 years (last time I checked) of employment before you're up to 4 weeks per year. This pales in comparison to contracting shops in the DMV (DC, Maryland, Virginia) area, where the smallest I've seen is 4 weeks for brand-new employees. Over the years I've seen more and more switch to unlimited PTO.

More likely than not, you will inevitably have to deal with a "govvie" who prides one's self on doing nothing all day and getting paid more than you for it, simply because of seniority. This might sound like hyperbole, but after 6 years as a DoD contractor and getting fed up with all the bureacracy, I left for the fully private sector and I haven't looked back since in 2 years. YMMV.

Fed benefit programs are usually better (lower deductibles, larger provider network) than what a private company going through Carefirst or another provider can get. Depending on how high up you go and how long you stay in, the pension can become very lucrative, in addition to a 5% full match 401(k) starting from day 1.

Granted the salary at the GS-14 and GS-15 levels are on the lower end than compared to Silicon Valley, but it's actually around what an engineer with similar experience can get in the DC/NoVA area, in my experience.

Not to mention that it's basically impossible to get fired as a GS unless you royally screw up. Usually this means committing a felony outside of work, or committing serial sexual harassment in the workplace, etc.

Note: I can only speak to the DC/MD/VA region but HOV lane privileges for hybrids and all-electrics aren't being granted anymore. The HOV lane on I-66 in VA was always clogged because so many folks bought Priuses that it defeated the purpose.

Agreed with all the other pros.

Using ".component-name <insert child tag>" goes against semantic UI conventions and couples your custom styles to the tags instead of the classes in the component. It quickly becomes brittle when trying to update those styles if the tags change in an updated version, or if the rendered output changes structure, etc.

Are you me? I'm in the exact same boat. It's not even just SF or NY - companies in Reston, VA or Tyson's Corner won't even consider even a partially remote schedule.

I've gone so far as to offer to commute from central MD to northern VA a couple times a week - no dice. Gotta be onsite every day in their open-office floor plan where 90% of the workday is spent with noise-canceling headphones on and almost all communication is through Slack.

It's maddening how the pendulum keeps swinging away from remote work in this area.

That's the most straightforward solution. I'm working on an Android app that syncs calls and texts to a Rails back-end and I try to keep the sync workflow as simple as possible. As for sync'ing, I found the following to be a huge boon for users:

- Allow the user to set sync to happen only when connected via Wi-Fi (not sure if this is possible in iOS, but it's easy to check how an Android device is connected to the Internet).

- Give options for sync intervals. Most of our users choose once a day. Other options include sync'ing a call or text right after it's finished or received if they need their data to be up-to-date within minutes.