HN user

arcticwombat

167 karma

Software developer, open source contributor.

Windows, OSX, Linux, web, desktop, server, system, plugins, I make a bit of everything

Posts1
Comments75
View on HN
Programming Idioms 7 years ago

Eh, what's wrong with Rosetta Code? A metric ton of examples in a metric ton of languages.

What's better about this one?

If your product can be built entirely by "t-shaped" people, it's not a complex product.

The thing about experts is that they're experts, an expert is INCREDIBLY good at one particular thing.

The idea of "t-shaped" came about as management didn't want to pay for "full-stack" people.

You know, people who are very knowledgeable in the entire software stack your product is built in (But are also experts on one particular thing)

Today it's a SCRUM sales pitch, that you can do more (development) with less (people) and thus save money.

What you're really doing is overloading the people you have, and usually expecting them to all perform at the expert level.

"Bob can do this in 2 days, why do you need 7?"

Almost no project has no "crunch time", and crunch time means you need to fly as fast as possible, you can only do that when everyone is assigned work within their area of expertise.

If you need experts, get experts, don't get fooled by the "Agile" sales people.

Remember, the agile manifesto is only a few lines of text, anyone selling you courses and books are doing just that, selling you stuff.

Sounds like a great project for you to learn a low level language, and some UX and GUI design at the same time.

Game development is done in several languages and frameworks, so it's not a big deal what language you go with as long as you learn to write good code and document it well.

Every tool, language, and framework has downsides and quirks, literally every single one.

Over your career you'll use dozens of languages and tools, if not more.

Stop fretting and start doing :)

Super clickbaity...

The dude had been prohibited from owning a gun after domestic abuse against his girlfriend.

He tried to buy one anyway and failed a background check.

He bought gun parts and a 3D printer.

Police heard him firing in the woods, when told to put the gun down he told them he was CIA.

Officers inspected McGinnis' backpack and discovered a hit list titled "9/11/2001 list of American Terrorists" that included the names of both Democratic and Republican federal lawmakers.

That's why he was jailed. Not just because he had "a 3d printed gun".

* Solve problems

* Afterward, reflect on what went well and what didn't

* Write down what you should have done differently

* Solve more problems, keep those notes handy

* Repeat

Sorry, not based on CS/Math puzzles, but real-world software development and problem solving.

I know how it's done.

Find a problem, solve it, charge for the solution.

All you have to do is fill in the blanks :)

It's not really tongue-in-cheek either, there are LOADS of books about this, but in the end it's all about finding a problem, providing a solution, and charging for it somehow (Time, licenses, platforms, whatever)

The best way to get there is to talk to people, don't ask them to think of products, just ask them how they go about their jobs and find out what the pain points are.

Where are they spending time on things that could be automated, or made simpler, or just eliminated by changing methodologies.

I'm the same.

QBasic, GW Basic, Commodore 64, those were the big ones for me as a kid.

Without them, I probably wouldn't be a programmer today.

I think so too, but my statement still stands.

There's nothing new or especially special about "server side rendering", and nothing about React rendering either.

Rendering on the server lets you do whatever you want.

Want to put the user in a specific state? Sure, go for it.

Want to use a starter or null-state? Sure, go for it.

Yeah microservices is another one that suffers from the One Solution To Rule Them All mentality.

They're GREAT when they're the right fit.

Most websites aren't really a right fit and do fine with a classic webserver->DB setup.

I'm not talking about the bloat of the framework itself but the code you write to use the framework.

When you have 2mb worth of "React code" and the framework itself only takes up 35.6kb, that's a lot of bloat.

SPA isn't automatically the best solution for a page or site with frequent updates.

The updates are handled by JavaScript and http calls.

You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.

2mb html file, + whatever else for initial load?

That's only 1-2 seconds on a fast connection.

If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.

Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

How is this amazing?

We've been "server side rendering" since the inception of the internet.

If you build your pages with CSS at the top and JS at the bottom you're already achieving most of that effect right there, no extra tools needed.

The browser will load the css and content first, and then process the JS requests (Which are easily cachable by the server AND the browser).

There are two kinds of "Productive".

There's my personal productivity, and there's the team/company productivity.

When working on a team, you have to figure out what produces the best output for the team as a whole, not yourself.

I function best when I get up at about 8am in the morning, and get to work at about 10am.

Doing that, when others leave in the evening I get several hours of high productivity.

My personal productivity soars when following this.

However, it means I'm much less available for the team, and depending on the project my being available has more impact on the team output than my direct personal productivity.

I have to say my experience tracks this too.

A lot of the "modern" toolsets just aren't worth the extra fluff they add.

Writing SPA's in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.

1. Because drones are really cool.

2. Because throwing cpu power at them to solve the stabilization issue turns it from a mechanical project to an electronics project, which appeals to geeks everywhere who don't have much of any fabrication experience.

3. Also, see #1 above :)

I'm the opposite of a morning-person.

I know some people enjoy audio books and whatnot, but I'm just trying to wake up so I just play some music from my phone (Over the car audio system), what I play depends on my current mood.

Everything from "Pickle Rick" to dubstep, lately I've been playing a track I use when coding.