hire_charts

This matches my experience. That's not to say that your application doesn't need to do any work on top of the data. Sometimes you need to interpret the data in different ways for different use cases, and often that means applying transformations at the application layer. But if you find yourself fighting against your own data model, it might be time to consider restructuring the data to better support your use cases.

I have a question. How would you know when you're using an iOS or Android app developed with React Native? Is it possible that you're only unimpressed when you actually notice something is off?

Because, in my experience, React Native is the first framework that actually feels native, and often results in apps that behave identically to their native counterparts. One of the big reasons for this is that it actually is using native components in most places.

Facebook's philosophy isn't that you should write platform-agnostic components and use them everywhere. They actually encourage using platform features wherever possible, but at the same time the way you write the components doesn't change across platforms -- "learn once, write anywhere."

It's easy to call out trivial examples because they're trivial, but you're missing the forest for the trees. His point is that the cognitive load adds up. One (null == foo) probably won't slow you down noticeably, but the more of these tricks and workarounds are scattered throughout, the more time you'll need to spend reading and understanding the code.

Sometimes the workarounds are necessary for performance reasons, or they're just good practice to avoid common pitfalls. But in a lot of languages they aren't, so unless you have a good reason for increasing the overhead, it's better to lean towards readability.

Edit: Also, for this particular example, a good linter is all you need to warn you about an accidental assignment. If you don't have a linter, sure, then put null first, but it's important to recognize that this sacrifices a small amount of future scannability for the more immediate avoidance of a bug.

A linter is also a great way to jump start learning a new language. If you encounter a warning that doesn't make sense to you, look it up. You'll start to get familiar with common language pitfalls without actually getting burned by any of them.

That's great -- and I'm glad you disagree. It's awesome to find a sustainable level of work that can be repeated like that, indefinitely.

I felt the need to speak up because I've seen contribution graphs EXACTLY like the author's and yours, except where the end result was not so happy. Take Zach Holman's for example:

https://zachholman.com/posts/streaks/ (chart is 2/3 down the post)

Zach's streak was great for him. Until suddenly it wasn't, and far too late he realized he was burnt out. He's been amazingly public about the whole experience (his subsequent sabbatical, then his being fired from Github, then his year of soul-searching), and for every public story like this I suspect there are many, many private examples that go unheard.

I think it's great when you can reach such a peak of productivity, like in your case. But it's important to recognize that you're kind of an outlier. The endless contribution "streak" doesn't work for everyone, at least not always and indefinitely.

I don't want to generalize about what is always a good level of work and what isn't. What I DO want to communicate is that it's important to be introspective and take periodic steps back to evaluate the sustainability.

After all, a level of work that seems unsustainable might turn out to be quite manageable, and vice versa.

Good to hear. I actually think that maintaining the streak is pretty cool -- even if it seems like an alarming pace at first glance. Sounds like you're taking a healthy approach to the project. Best of luck!

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already:

https://zachholman.com/posts/streaks/

-------------

Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.

Here is his Github contribution chart:

http://i.imgur.com/d1IA1if.png

This... does not look like a sustainable level of work. 100 straight days of coding since last December? Yikes.

This sounds like an interesting project, founded on good ideas, but sustaining this level of work will do no good if you burn out before there are other contributors to pick up the slack. I know that a lot of people can keep working this hard for much longer, but quality will inevitably start to suffer, well before you actually burn out. And, at the very least, you need to take the time to step back and validate your ideas. This is something you'll never do if you're always heads-down coding.

I'm not saying that taking more breaks (weekends off, etc) works for everyone, but I just thought something needed to be said. I've seen friends and former colleagues fall into the trap of working on a project so deeply that it becomes a crazy obsession that they cannot escape. It's all they talk about and it can kind of scare people away. Not saying that this is such an extreme case, but it's something that can happen if you're not careful.

Fair point.

That said, I'd argue that chefs, plumbers and doctors do benefit from the ability to solve their own problems with whatever tools available to them, and I'd still include the basics of programming in that list.

It's a narrow view of the world to assume that the only problems you can solve with code are the problems you'd hire a software engineer to solve. Much like the ability to communicate with words, or the ability to manipulate spreadsheets, coding is just another skill in a long list of skills that help individuals approach problems in new ways.

Do you need to know calculus in order to be a chef? Probably not. Does that mean we should stop teaching calculus in schools?

I liken "Everyone should learn to code" with "Everyone should learn to write." Neither of these statements claims that by learning the skill you are suddenly a qualified industry professional. It's about having a basic working knowledge.

Simply put, knowing how to write (in, say, English) won't make you a published author in the same way that knowing how to code (in, say, Javascript) won't make you a software engineer.

Or, another way of looking at it, by knowing the basics of a programming language you unlock the same kinds of jobs that were historically available to people proficient with Excel. Sure, you're no programmer, but at least you can hack an analysis together with a few basic tools and pass your findings around via email. These skills are not the focus of your job, but they do help you get your job done.

Yes, this is where, in practice, I've seen the adage used incorrectly. Even when Knuth isn't quoted directly, the idea that "premature optimization" is inherently a bad thing has led many a web developer down the path of terrible architecture decisions. So I understand Duffy's point exactly.

It's not that all issues are preventable. It's that you can prevent a lot of them with just a little extra work up front.

It's a misuse of Knuth's original point, which has much more to do with how brittle and incomprehensible "optimized" code can become.

Cache-Aside is an Antipattern. It forces you to define your caching logic at the application layer, and suddenly the app must care about--and actually implement--your caching strategy. This is very difficult to scale correctly and is a common source of stale data and race conditions.

Better to treat caching as part of your overall database infrastructure. If caching "hot" data is really important for your app, make sure your data layer supports read-through and write-through caching. Or use the "CQRS" Pattern and read from a different source than your writes (allowing your writes to transparently apply whatever underlying caching strategy you need to support the reads).

The MSDN article on CQRS actually has some good advice on combining it with Materialized Views and handling consistency issues. Worth reading if you're interested in solving your caching problems.

I'm not sure how much of it is that google tries to reduce the effects of SEO, or that they just keep moving the target. Every time they change their algorithm it seems like a bunch of sites who were practicing one strategy disappear, and before long a new strategy is discovered causing new sites to rise to the top.

Ultimately Google's ability to quantify both quality and relevance will converge on actual quality and relevance. In other words, the way to "game" the system and practice SEO will be to create a site that is actually relevant with high-quality content. But we're not there yet, and who knows how close we'll actually get.

One thing that helped me was to actually implement things that made use of the "algorithm stuff." Not just practicing in front of a whiteboard, but real executable code!

In particular, anything involving a Tree was never very intuitive until I tried implementing a script to search for files by name. Suddenly both the recursive and the iterative approaches made sense. I understood the trade-offs because they applied directly to my work. That opened the door for more complex algorithms, like a Huffman Coder (which I wrote in C, as part of a CS class).

The other thing that helps me in interviews is to just talk through everything I am thinking. It feels like I'm stating the obvious over and over, but a good interviewer will be able to follow your thought patterns and help you along when you get stuck. Also it just helps to hear yourself say things outloud sometimes. If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.

If you stop paying (e.g. if they increase prices on you), you lose the ability to publish new content. This is different than "free forever." Their "promise" is that existing content will, to the best of their ability, never disappear from the web.

The biggest API integration I know of is Splitwise. Their Android app has 500K+ installs and it's probably the same ballpark on iOS, which puts them leagues above a college kid with 2 likes.

Okay! (see above)

That and Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

Both of these talks are in my top 5.

Edit (okay, here are the other 3):

* All the Little Things by Sandi Metz https://www.youtube.com/watch?v=8bZh5LMaSmE

* Programming is terrible—Lessons learned from a life wasted. https://www.youtube.com/watch?v=csyL9EC0S0c

* Some talk I saw by Dan McKinley on making Data-Driven decisions. I can't find the original video, but here's a really similar one: https://www.youtube.com/watch?v=SZOeV-S-2co

Now that Chrome supports notifications (on Android) I was able to uninstall the native Facebook app and rely exclusively on the web version (which actually loads faster for my anyway).

Still have the icon on my homescreen, still get the same notifications -- the main difference is how much better my battery life is now!

The problem is that this kind of workflow -- where someone iterates through multiple versions of a file or folder, renaming them each time -- results from the work they are doing offline and the lack of offline version control usage. Adding a step where you drag and drop your iterations into a website might only add to the confusion, rather than actually alleviating that pain.

Agreed that this is a great approach, but the major downside is that you are limiting yourself to candidates who either:

a) have the time to do real work outside of their day job and aren't on a restrictive contract preventing them from moonlighting, or...

b) are currently unemployed

Presumably you (the employer) have less time to do on-site interviews than to assign take-home projects, so landing a real interview is a much better indicator that my (the job-seeker) time will be well-spent. (Hiring is a two way street.)

> The bad part of this is the disappearance of WYSIWYG editors for HTML. You weren't supposed to write this stuff by hand.

It really doesn't matter what you were "supposed" to do with HTML. It's become something entirely different than what was originally intended.

When Tim Berners-Lee was at CERN he really just needed a way to link research papers to one another when, for instance, one cited another. His creation of the 'Web' referred to a web of mostly static documents. Nothing like the interactive applications we have today.

The fact that no WYSIWYG editor can keep up with the latest front-end application design trends is no surprise. (Would you expect a WYSIWYG editor for your iOS app?)

The amazon links did not have 'tag=' which is what the referral program uses. They just had 'ref=' which is what amazon uses to track how you got around the site.

Regardless, the author has since removed the links.

This is just cruel. I hope you left that job.

Agreed. There is no need to use a custom flavor of BEM.

You might be able to enforce a distinction between elements and modifiers (with elements nested below parents, while modifiers are siblings of the elements they modify) like so:

  .accordion {
    .accordion-item { }
    .accordion-item-selected { }
  }

But this requires nesting where true BEM otherwise avoids it.

Is lifeprotips.com the site you were trying to promote? I see that the banners are really similar.

You are correct. I was responding more to this:

> easy to install, relatively easy to use, with good reliability, for experimentation

The major difference though is that react is a self-hosted open source library. Yes, Facebook could drop support for it, but there are enough people using it now that it would probably see community updates for quite a while.

Definitely neo4j. If you're on a mac, it's just 'brew install neo4j' and boom you have the free community edition.

bup is great, but it's worth reading through the limitations before you commit:

https://github.com/bup/bup/blob/master/README.md#things-that...

Because of the nature of bup's solution, there are some operations that haven't been implemented because they would be prohibitively expensive. Pruning old files for example -- the equivalent of git's "filter-branch" just doesn't work.