glimcat

It's almost impossible to give politicians a hot-button campaign topic without them over-reducing the problem to a counter-productive KPI, which they will then tie funding to.

There's nothing wrong with deciding you don't want to climb the management ladder, but getting "un-promoted" is something where you'll probably want to find a new job. Fortunately, almost everyone is trying to hire competent senior developers, so you should be able to find a new gig before too long - and probably get yet another pay raise to go with it.

Take specific_problem we were just discussing, you really don't want to slot in a generic developer there because Y. Whereas I've dealt with that problem before and would instead do Z for you, saving you much time and profit.

Because of this, the low end of the range we should talk about is really more like $N > market average. Why don't we come back to that, and talk more about the problems your team is going to face this year..."

Usage:

You have to tell Postgres to use the HSTORE extension for your database. It's shipped with 9.3 but not active by default.

Then for SQLAlchemy you'd add something like this in your models.py:

    from sqlalchemy.dialects.postgresql import HSTORE
    from sqlalchemy.ext.mutable import MutableDict
    
    class Widget(db.Model):
        id = db.Column(db.Integer, primary_key=True)
        data = db.Column(MutableDict.as_mutable(HSTORE))

It's nice because it's an RDB field so you can do all the usual Postgres love when you're not wanting to store a dict(). Or you can just do a table with id, data, and id can even be a kv-style key if you want some sort of meaning attached to the primkey. Plus it's dicts, and Python is heavy on the dicts, and it's a quick leap from there to JSON.

Not the only one I can use, but I prefer working in Python. You could also count tools like scikit-learn and NLTK as part of my "stack" although they're usually not called in direct response to an HTTP request.

Really, most talks from Business of Software & MicroConf.

Highly-sorted posts are almost certainly an edge case, but convolved against other factors (e.g. relative popularity of C#, how well post resonated with the subset of hiring viewers who ended up seeing it). Whoever ended up with post #70 likely got far fewer views relative to post quality & desirability factors, and thus fewer responses.

But at the same time, "uncommon yet high-demand" keywords probably got a Ctrl+F bonus. It's an SEO problem as much as a pitching problem, and more so if you're not favored by HN's comment sorting.

But, I can see it helping for people who are less experienced or confident or whatever and likely to take job posts at face value instead of as a signal of the problems the company is trying to solve through hiring. It would be better to get past that obstacle, but pragmatically it may have its uses.

* subject to far less stringent controls

* much less likely to be participating in a lengthy appeals process

* subject to corrupting influences such as for-profit prisons

* vastly dominated by "plea agreements" in which people are convicted via coercive influence rather than any evidentiary process (and far worse if socioeconomically disadvantaged or non-white).

If 4% only refers to death row errors, the overall error rate for wrongful convictions is likely in the double digits.

Also, the error rate probably goes up again for non-incarceration results which let the system "slap people on the wrist" since that is seen as less serious (despite high incidental cost to life, career, mental & physical health). It's the legal system's equivalent of closing a support ticket.

And this is only classifying "correct judgement" vs. "wrongfully convicted." It fails to model cases where a criminal conviction was a really stupid way to deal with the problem, which could have been addressed via non-criminal means.

And if I want to attach non-kv data like last_updated, or have foreign key relationships between one dict() and some other stuff like the corresponding user record's primary key - it's already in an RDB.

Because you can often get a less corporate job doing work you enjoy more with people you enjoy more while still having manageable risk and progressing your career. That goes triple for software engineers in the Bay Area, for whom "out of a job" is a minimal risk that frequently results in a pay raise.

People mostly don't work for startups for the lottery ticket. Equity isn't really compensation, or shouldn't be taken as compensation, so much as it's a social signal. And even then, equity is more about investors than employees. Equity only evaluates to any sort of compensation at all in the event of an exit, in which case they want the senior staff to have some degree of additional incentive not to immediately leave for a new gig.

Buffer offers a choice between extra salary or extra equity. Every single one of their engineers is taking the salary election, while it's mixed for other roles.

Want good people? Don't undermine your ability to attract people who are investing in themselves as much as in you, or who have families and mortgages to worry about.

It might help a few young engineers who have only ever seen toxic hiring practices and assume that's how it ought to go.

    ['FizzBuzz' if 0 == n % 15 else 'Fizz' if 0 == n % 3
        else 'Buzz' if 0 == n % 5 else str(n) for n in range(1,101)]

Oh, and if an admin logged in at any time during the window in which you were vulnerable to Heartbleed, or if any similar credential ended up in memory in any way during that period - consider yourself rooted.

Heartbleed is a "burn down the server, redeploy, restore database backups, expire all credentials" event, not just an "apt-get update, done" problem. And it hit over 2/3rds of HTTPS websites (ideally: anything with passwords, then some).

The analogous situation for graphics design would be something like textures & Photoshop filters. Or icon packs. Or fonts. Which you can find lots of for free (sometimes even with useful licensing attached).

But who the heck is going to come do free graphics work for my new Flask extension when they don't even use Flask, or understand what it is, or have any motivation beyond "hey come do free work for me"?

On the other hand, you have cases like the current mpld3 logo update. The project's author asked for help with the logo on Twitter, and got 6+ solid responses back. People are glad to help if they have the skills to do so and if they're part of the project's community. Design vs. development is not relevant, only relevance is relevant.

https://github.com/jakevdp/mpld3/wiki/Logo-Proposals

Sure. But there's always the competing option of "work for a socially ambivalent megacorp which pays more, then donate the delta to your cause of choice." Or more commonly, "I have three kids and medical bills, and am not free to arbitrarily take substantial pay cuts."

Go to the edge, then add a bit.

Or, whatever, get two computers. Or twenty, they're cheap.

It sounds like time to get a better job, with a healthier employer, working on something more interesting, and making at least 20% more. Or take a run at building your own ship if that interests you and if you have the financial padding.

I never counted students off for comments, although I also never worked with a professor who had a policy of "All Code Must Be Commented Or Else." I don't think many professors did, at least not for upper-division classes. Perhaps related - most students didn't comment at all (I largely dealt with CS seniors).

Then we had a bunch of students get counted off for bugs, unimplemented features, or general weirdness in their code.

As a rule of thumb, the very few people who did comment got much better grades simply because I was allowed to give partial credit. If they at least commented what the heck they were trying to do and how, and why they thought it advanced the project - I could probably figure out what went wrong and award points accordingly.

You know that Tolstoy quote, "Happy families are all alike; every unhappy family is unhappy in its own way"?

It applies perfectly to bad code. Whether we're talking university or industry, having SOMETHING there so that your teammates or the senior developer on the team can figure out what you were TRYING to do is an enormous help.

Going comment-light is fine in a perfect world where you have concise, elegant code that works perfectly and is absolutely clear when you come back in six months and try to figure out how you structured the program and what role any particular snippet serves within the greater whole.

It's not a perfect world.

(At the same time - readability functions such that if you put a bunch of trash comments in, people reading your code will assume that most of the comments are trash. You can't just tick the box and expect that to be enough.)

Code in this pattern is often a compromise, and may be found as contributory to future issues, but it probably didn't merit a follow-up task at the time of writing.

Yes, assuming there's not some contextual reason why hardware acceleration is obviously inappropriate. But even then, it would be much better to err on the side of "assume the next person to read it hasn't had their coffee yet."

Even something like "don't use hardware acceleration because compatibility issues" would be a better comment. You don't need an essay. But it should be both concise AND descriptive of the issue, not just normative or prescriptive.

Not everything needs an open issue, but the knowledge should be recorded somewhere. I know for a fact I won't remember it in six months, and likely not in a week either.

(I also write a large amount of utility code that's below the "project" scale and will probably never see a PM tool, but which is nonetheless part of a heavy reuse ecosystem.)

It's not a TODO or a BUG, but it's helpful to make note of for future code review or reuse.

(Probably other registrars support it as well, that's just the data point I have first-hand knowledge of.)

I can do "right click + copy link" on DuckDuckGo and get a clean copy of the link. That isn't the case on Google.

Initial version, use Unbounce or Squarespace or whatever gets you moving with the least wasted effort.

Later on, you probably want a CMS so it's easy for non-technical users to update. WordPress is happy because of adoption levels, then throw money at WPEngine to handle many of the more common issues for you.

You could use Drupal or some custom thing if you WANT...but make sure you have a benefit equation that justifies it. The more custom your solution is, the more maintenance overhead you commit yourself to.

For stuff like landing pages, set up a site style guide. It may also be helpful to standardize on a style library like Bootstrap or Bourbon Neat. Don't make people reinvent the wheel every time.

Then add tools like Optimizely, Woopra, Kissmetrics, Intercom, Snappy. Your major bases to cover are generally testing, tracking, and customer interaction.

It may also be helpful to add a content management tool like GatherContent. WordPress may be easy to update but planning what to update and aggregating assets for it is a completely different problem.