gedrap

Yes! I was looking for something similar to create a basic database in order to really understand the underlying concepts, but couldn't really find anything.

I considered this, but the options are very limited where I live (Lithuania). We have a few high quality local roasters, but even they have only one blend of decaf (and dozens of normal coffee).

I am a coffee drinker but I don't really get boost or anything. Nor do I feel tired or anything else that could be called withdrawal during the weekends, when I don't drink it.

For me, making a cup of coffee is just a... ritual of sorts. Weighting the beans, pouring over water, all these things. And I really enjoy the taste, trying different beans. I don't want to sound pretentious, it's just a hobby for me.

Maybe there are some alternatives to it (tea?) that have lower impact on health over time, but I haven't really explored it.

Absolutely. I'm a backend/infrastructure guy and spent a lot of time creating internal tools with web interfaces over the past 3 years. Thanks to Bootstrap, they look decent, modern, took very little time and people were happy to use them. Sure, not the most original designs, but that's light years ahead of crappy interfaces I'd have produced otherwise.

Some engineers like to complain about 'yet another bootstrap template' a lot, and I can understand that it gets a bit dull and boring, but that's much better than the alternatives.

Out of curiosity, what percent of companies just outright refused to consider remote work? And of those that considered you, how many had no remote engineers or didn't really have the processes in place to support remote work?

Because, I think, working remotely it's not just something that you, as an organization, do. Getting it right, in my experience, requires active effort.

I know that applying on jobs pages is not popular here on HN but, well, sometimes it works. In my opinion, having some projects on GitHub certainly helps, even if they are just hobby projects with no use in real world. So it doesn't mean that you must spend months working on open source projects on the evenings and weekends, hoping to get noticed. Same for technical blog posts. It definitely provides more signal to the person who is reviewing your application.

Also, very few companies are 100% remote, and making remote team work is not trivial, so it's important to ask the right questions when interviewing. Don't forget that's it is a two way street! Personally, I was looking for these two key things:

- at least ~30% engineers should be remote;

- there should be a strong culture of written async communication.

Once I discovered a company which I found interesting ( https://heapanalytics.com ), checked the jobs page, noticed that they are hiring remotely and just applied a few months later. Had several interviews over video chat / slack, no white board coding or CS trivia. In the end it worked out and I got an offer. Totally recommend applying at Heap - we are doing cool and challenging technical things (querying hundreds of TBs of data in seconds and making it reliable), the interview process is great and our small distributed remote team is made up of engineers from 4 continents, from North America to Australia!

I think it really depends on the use cases. For example, if you are in a team of 5 engineers, all working on mostly unrelated areas, then no problem. In this case, you might go a long way without having an actual need to learn something more advanced.

However, it's quite important to recognize when your basic git skills are not enough anymore. Which often is joining a bigger team/company.

A lot of news consumption is driven by Facebook, and Facebook is pushing videos rather aggressively lately. It's very likely that these are related.

Nice feature of stud.io is that it shows prices of all bricks, so you can cost-optimize your model in case you decide to build it.

Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example:

> Call your shot. Before you run code, predict out loud exactly what will happen.

M, okay, but what exactly do you mean by that? Or even poetic, kind of:

> Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act.

I have no doubt that each point has some very specific examples behind them and knowing them could actually be useful. But right now, you can only guess what was intended behind these #deep thoughts.

Personally, I don't think that it's even a right format for questions which are not part of a larger discussion (e.g. deciding on details of some issue or PR).

I have never seen link to gitter in google search results, and answers vanishing forever (not sure how good gitter search is though) does not sound good. Once I joined a few channels because I wanted to ask maintainers a quick question if $xyz sounds feasible or am I strongly misunderstanding things, because had some ideas how I could contribute. These were rather popular repos and all channels were full of low effort questions that could be either google-able or answered by spending a few minutes playing around.

Money and income are more complex than that. It is related to ones sense of self-worth, fairness, etc. Ideally, one should try to detach money & income from these senses, as it is a pretty much lose-lose situation. But it's not easy and I think recognizing that it is the case, that it does have impact, can go a fairly long way.

Personally, I found that TDD works very well for small modules / classes, etc, when there's little design to be done. In this case, you can focus on writing down the spec (test cases) and be fairly confident that it works by the time all test cases pass. Also, I agree with the author about complexity involved if one decides to go down the TDD way for large, complex systems. So, essentially, it boils down to picking the right tool for the job, and TDD is just a tool, like any others.

Excuse my ignorance but how is it better than googling the symptoms and eventually getting to cancer for pretty much any symptom? That's a serious question, though. It's not suddenly you will be able to cure yourself and save trip to doctor's office.

> incredibly hand-wavy and he essentially admits to making them up whole cloth

I get what you are saying, and I agree to some extent. But I think the key in this post was that the 'average' game (from the very middle of indie top sellers list) makes next to no money. Checking it did not require making many assumptions. And this point is valid.

> One of my favorite things about the stock market is you know exactly how good you are at all times. Your bank roll is your track record and its very black and white

In the very long run, yes. But if you apply this to a short term (a week? a month?), that might lead to a rather fatal ego boost. I believe, that this is something that everyone interested in trading has to be aware of.

This is a noble effort but your post is missing one key answer: is this person motivated enough to do it? Or just needs some money right now and maybe for the next month or two?

Coding is hard, and takes a lot of hours (like, a thousand or two) to get to basic proficiency. So yeah, you need a lot of will power and motivation to get it done. Especially outside formal setting like university, where you are pretty much forced to do it.

I know plenty of smart people who have uninspiring jobs with low salaries, and they keep talking how they will learn to code, but they don't manage to go past hello world.

This book has similar ideas about basic practical applications of python https://automatetheboringstuff.com/

>> industries where it's very difficult for new blood to break into

What are examples of such industries?

I think that one of the reasons why awareness is still relatively low, is that it is often hard to imagine the implications of this for the casual internet user as HN is quite a bubble in this regard.

And by implications I mean something more than not seeing job ads, or not getting a loan.

Fortunately, there are no such cases that I am aware of. Unfortunately, it might be just a matter of time.

>>> people trying to raise awareness for this issue, are harmful

Harmful for who? If, let's say, they make people actually aware of this, that might lead to change towards privacy. But if people are unaware, and they remain unaware, the probability of change is smaller.

I think that Slack (or any other IM client for work, really) is just a tool, not a solution. Meaning that it requires some organization and thought, rather than installing and hoping for the best. At least to some extent (i.e. have no idea about companies with hundreds of engineers online), it works. Equally important it is to acknowledge what is suitable for doing on IM and what is not.

If you want to discuss some large changes, sure, IM is a bad place. Conversation will probably get interrupted, derailed, etc. That's where, in my opinion, things like Google Docs or plain simple GH Issues shine. The format forces into better thought out, longer messages.

For other things, you need to organize the chat rooms. If you have 10+ people and 2 chat rooms (I think slack defaults to #general and #random) then yes, sounds bad. But instead having quite a few chat rooms with <10 people each might work out well. Even having multiple rooms with the same people can be good to separate different topics of conversation.

"Always on", I believe, comes not from the IM itself but from the culture of the company. I know places where everything is e-mail only and people constantly refresh it. Equally, IM is mostly ghost town outside working hours at other places. And Slack has decent notification settings to make sure that you don't go crazy.

So, IM has it's place and provides value if you are willing to make it work. It's just not a 'it just works' solution, which is hardly surprising.

Even the 'good' metrics you listed are not that good and can be easily gamed if they are important enough, e.g. can influence salary, etc.

Happy customers is the only exception, but it's essentially impossible to attribute this to a team or an individual and is more of a company's health metric. You could just replace it with revenue.

>>> products shipped, features delivered per team

Will lead to releasing products that should never be released, or releasing too early, or creating a lot of features just to increase the counter.

>>> bugs fixed

Then why ship quality product in the first place, if it is more valuable to have easy bugs to fix later?

>>> documentation written

Can result in poorly written, or way too detailed documentation which will go out of date the next day.

>>> individual git commits

Some people commit more than a dozen of times a day and happily push them. Or you can create tons of commits that deliver very little value (e.g. adds a single comment), but increases the counter.

I understand that it is all well intended, it just seems like it creates a game rather than solves a problem. Some people are great at adapting to games and rules, some people - not so much.

Quantifying developer's work has been discussed a lot, and I am still largely skeptical about such low level metrics. Essentially, it motivates people to maximize the score, even if it means doing things that are only good for the score, instead of good for the company.

I had experience with this kind of employers in my very young days, when time and time again 'probably something wrong with the bank' or dozen of other bs excuses.

If you are inexperienced, very short on money (e.g. a student), and have no one to discuss these issues with, rationality might go out of the window. You can convince yourself that everything will be fine very soon, you will get your money next week, etc. So it's not very surprising. Quote from the original Medium post:

We had 8 young Chinese employees on H-1B visas with us as developers, limited in experience but eager to please and learn. They end up being the ones to suffer the most.

https://medium.com/startup-grind/i-got-scammed-by-a-silicon-...

Sounds more like a design decision - don't exclude documents, where there is a low probability of relevance. For various reasons it might be better to have more results with some irrelevant ones, instead of 7 highly relevant ones.

I was reading "Building Microservices" by Sam Newman, he mentioned that some of his clients moved from monolith to 300+ microservices without going into details, so yeah, that made me wonder about it as well. (it was a decent book otherwise).

Yeah. Although personally, I think that it's still not as bad as the "James from FoobarSaaS" for the technical products (you know, CI, etc).

It was new and cool a few years ago, and maybe non-technical users find it more trustworthy, personal touch, whatever. But when you get this crap daily, it's just a bit silly. There's nothing personal about spam and I don't even know if the "James from FoobarSaaS" person actually exists (probably not).

Define fun. If rewarded, taking a team with shitty development processes, poor software, etc and taking it to the next level can be a great fun. But only if it is reward, i.e. is considered valuable.

But does it solve any actual problems other than 'XML is not cool', problems big enough to deserve a new format?

It's true that JSON is easier to deal with than XML. But that's relative, there are plenty of decent tools around RSS. From readers, to libraries in the most common programming languages, and extensions in the most common content management systems. JSON is slightly easier to read for human (although that's subjective), but then how often do you need to read the RSS feed manually, unless you are the one who is writing those libraries, etc. But that's a tiny share of all people using RSS.

>>> It reflects the lessons learned from our years of work reading and publishing feeds.

Sounds like the author(s) has extensive experience in this field and knows things better than some random person on the internet (me). But the homepage of the project doesn't convey those learned lessons.

To be honest, I am fairly surprised at the reaction here on HN. It's not really surprising to see such system, it would be more surprising if such system did not exist because offline ads is a huge business and the technology is here. This goes together with conversion tracking at physical shops, etc.

I am equally surprised by the comments about how come engineers implement such systems, how they find it ethical, etc. I'm sorry, but it sounds just a bit out of touch with the real world, or just outside of HN bubble. Given the things that money motivates people to do, it's probably one of the least unethical things that has been done.

I am not judging that this is right or wrong, I am simply stating the fact that nothing about this should be surprising. Yes, this is slightly sad, but that's simply the reality of technological advancement. It's not really possible to expect the rest of the world to use the technology only for things considered 'right', etc.