powatom

Building anything that rivals Wordpress in terms of features, extensibility and ease of use is a massive undertaking.

Building a CMS is relatively easy.

Building a CMS that does everything WP does is difficult.

Building a CMS that does everything WP does whilst still remaining easy to use is incredibly difficult.

There are plenty of blog alternatives out there - but few that you can turn into virtually any other kind of system in just a few clicks. WP can be turned into a whole host of other 'types' of website and you don't need to know anything particularly technical in order to do it.

Even installing Wordpress itself is just a few clicks (depending on your hosting provider).

WP is terrible in lots of ways, but in the ways that most people care about, it does a reasonable-to-good job.

Great news, the Gear is an awesome piece of kit if you have the cash, I'm planning a few projects with it myself.

You don't need it, but it may come in handy. I would definitely recommend achieving your degree if you are able to eventually - there's no way it can hurt you and it can only really help you.

I also didn't realise at the time how much I'd actually gained from my degree until several years into my career - not sure how it works in the US but I imagine it's pretty similar to the UK - being able to choose which modules etc you take means you can round out your education and expand it into other areas which may help you depending on which direction you want to take your career.

Generally speaking my principle is that any education is worthwhile. Software development isn't an industry which technically requires a degree since barrier to entry is relatively low and there are countless free educational resources out there anyway. That being said, having a formal qualification in the subject will increase your visibility somewhat - it's still true that a degree carries weight regardless of the subject.

AR so real that your augmented gun will actually recoil!

I can't help but feel that all of these complaints about low pay etc are just a symptom of the new reality. I don't really understand what people are expecting here. Distribution costs are minimal, audience is (kind-of) locked-in, discovery is relatively simple. The risk is almost entirely on Spotify's end of things, rather than the artists. Yes, without the artists, Spotify doesn't have a business - but without digital streaming services like Spotify, users could easily end up under an iTunes monopoly which probably wouldn't be good for anybody (although I believe - may be wrong, but please correct me - that iTunes does give artists a better deal currently?). The world is going digital, and people want to stream stuff. That's just a fact. Sure, many people will always buy CDs and LPs, but there being 'no money' in recording music is hardly a new phenomenon - people have complained about it for years before digital streaming was even a thing.

I really do have sympathy that there isn't much money in recorded music, but I do struggle to find a justification for why artists seem to think Spotify should be paying them more other than the fact that they just 'want' it and need to make a living. I understand that completely - and honestly I'd probably pay a higher price for Spotify if they demanded it and the extra money went to artists.

I think the problem is this: the music industry in general has exploited artists for years. It is not a business that works in the artist's favour, unless those artists are extremely popular (and even then, labels can seriously fuck artists over if they want to). Outside of the superstars, musicians may (not always, but often) fare better when they organise their own affairs - live performances, commissions for work, appearances, media, collaborations etc. They probably won't get super-rich doing this, but it could be a decent income for the right artists. What we have instead is a situation where artists create music for a (more or less) one time cost (recording, mastering, equipment, studio time etc) and then hope to make the money back through physical sales, royalties, and performances. The problem, I feel, is that the initial costs of production are still high, but the distribution costs are now incredibly low, which means end-consumers are reluctant to pay higher prices. I don't see any way around this other than altering the nature of the business itself. If production is always going to be a costly affair in the music world, then income from royalties through services like Spotify are destined to be considered low.

I honestly think there's no real hope for any significant increase in income through digital services. Why should there be? There's no technical reason to increase fees - distribution gets cheaper all the time. The only way to increase royalty payments generally is to either cut into profits, or pass the increase on to the customer - neither of which are sensible business decisions unless Spotify's hand is forced.

We don't really have a profitable relationship with music - the value we attach to a single track on iTunes or Spotify doesn't reflect at all the costs to the artist - but unless artists can convince consumers to start paying a lot more, I just don't think they'll see significant returns from recorded music any time in the forseeable future. It's just not an industry that pays particularly well. Production costs are high, distribution costs are low. Unless we alter the way music is produced, performed, and experienced, people won't feel like paying more gives them any extra value. It's an uphill battle.

I wish things were better for artists, but I just don't see a way out of this is that doesn't involve massively increasing price at the point of consumption.

Sore losers.

IANAL, but does this just mean that you can use and amend their work, but you can't create the same basic thing from scratch and claim that you created it?

Can't say I'm surprised - the GIMP is great if you can avoid all of its glaring UX flaws. Using it is a gigantic pain - it is simply my 'last resort' when I am unable to do something quickly in a less powerful but easier to use piece of software.

Maybe this is a good thing.

This pops up every few weeks / months and not once have I seen anything tangible from them. They refuse to offer a 'try-before-you-buy' demo and there's no way to actually see the tech work. You have to pay for a year's subscription, with no release date for the actual product other than 'late spring', with e-commerce coming 'late 2015'.

I would have a lot more confidence in handing over my money if they'd release something that people could actually look at and determine whether it's worth the price. The pre-order price is not really that expensive, but they have over 20k pre-paid subscribers waiting for anything with no visibility of actual progress other than slick marketing.

Maybe I'm just a cynic, but this just feels like it's going to be a disappointment.

The idea behind the app is this - every question in this world can be asked in a simple short way, even complex questions can be asked in multiple short questions. The same goes with answers - every answer can be broken into multiple short answers.

Are you sure this is actually true, or is it just wishful thinking?

Complicated concepts cannot always be distilled into 140 characters, and not all questions can be answered in such a short space or indeed, in such a format. I would imagine that the vast majority of the questions and answers will be trivial, which in itself is not necessarily a bad thing, but it does mean that for any detail, users will need to look elsewhere.

This feels basically like one of those Twitter Poll apps, although many (most?) charge for their features.

Don't give up, but I think you need to focus on detail - otherwise this is just Jelly (https://itunes.apple.com/gb/app/jelly/id685652528?mt=8) with a less interesting UI.

The easiest way to train yourself is to define strict boundaries for what you will achieve during a defined period of time.

If you have trouble focusing, the worst thing you can do is leave your attempts completely open-ended and vague. Define precisely what you want to achieve in an hour, and then give yourself an hour to do it.

If you don't get it done in an hour, stop and take a break, then give yourself another hour to finish it and start the next thing. Work in well defined blocks of time - the point is not to get good at 'doing lots of things within an hour', but 'sitting down and working straight for an hour'. Once this isn't a struggle for you, bump it up to an hour and a half, then two hours etc. Don't avoid breaks - your brain will continue to work problems out while you're off making a cup of tea or getting some air.

If you need practice, then you need something to practice towards. Give yourself boundaries.

Possible the best advice I can give for your current position is to get into the habit of starting and FINISHING personal projects. Doesn't matter if they're unique, or whether you think it can profitable, or whether you think anybody but yourself would use it. Do it anyway and make it a habit to finish. Then, when a good idea comes along that can change the world, you'll have practiced persistence.

I suppose the issue would be that Amazon are now directly competing with Netflix via their own video offering, so may be reluctant to give Netflix the means to outdo them at their own game.

In my own personal opinion, Amazon's UX for video is not all that great either, so it would seem both parties have plenty of room to innovate in this space at least, which can only be a good thing. I'm paying a subscription for both, and although I currently use Netflix more, it really wouldn't surprise me if Amazon started rapidly working on their video UX - they've got 'buying stuff' down to a tee, so it'll be interesting to see what they can do with streaming video.

You do what everybody else does, and keep trying. What kind of work are you looking for? In my industry (software development), it'd be incredibly rare to have a job interview without some kind of technical component / test. If you can demonstrate via your CV and application that you've got the goods, then hopefully you'll get an interview and the whole experience thing won't matter so much.

Basically just tailor your CV to highlight what you've got to offer, and then just keep applying. If you're a good fit for the role and can demonstrate that, then few places are likely to hold hard and fast to the experience rule. Experience is only a general 'easy' way of assessing somebody's suitability, but there are enough terrible employees with decades of experience under their belts to prove that it's not a guarantee of quality.

Also: https://identityassurance.blog.gov.uk/2014/10/09/how-we-use-...

Left a comment there but it's awaiting moderation. The GDS do a good job for the most part, but I very strongly disagree with how they're handling this one.

You will always find some developers who disagree with the status quo - don't let it turn you off.

Fragments have their place. They're not a silver bullet, and they're by no means perfect, but they do a job adequately. Some people will struggle more with fragments, it depends on what you're trying to achieve really.

Fragments are just the current 'Android way' of handling this type of scenario. It doesn't mean you have to do it that way, or that there's no other way to do it. It's just a convention and one which you're free to use or lose as you see fit :) The fact that fragments exist at all is at least some kind of help - imagine how shitty support for different form factors would be without them.

As for my own experience, I don't particularly LOVE working with Android UI, but it's not like it's the worst thing in the world. It's bearable.

Basically I think the issue is that by its nature, Android UI is going to be difficult. The Android devs have to support a huge variety of form factors, and they have to make some effort to abstract all of that so that app developers don't have to worry so much about it. It's a fundamentally difficult thing to achieve - there's never going to be a 'one true way' that works for all scenarios.

The nature of exploitation is that the exploited often do not recognise that they are being exploited. Being exploited introduces so many other problems into your life that it becomes incredibly difficult to identify the root cause and do something about it.

There is a shortage of good developers almost everywhere.

Most organisations don't required 'good' developers. They require 'good enough' developers. If a business can save some money by paying people less, they will.

If you don't like your job get another one.

Actually, I love my job - but this is a ridiculous argument to make. If it was that easy, why would anybody stay in a job they didn't like? Life's not that simple.

If you're a good developer you won't have a problem finding one, and your employer will probably learn that you are not easily interchangeable.

So your solution to poor working conditions is to teach your employer a lesson by giving up and leaving, so they can hire somebody less qualified for less money but who still manages to muddle through and deliver?

The problem with saying that 'there is a shortage of good developers almost everywhere' is that it's completely subjective. What are you classifying as 'good'? Does your employer's definition of 'good' match up with the share-holders definition of 'good value'? This is precisely why developers can be so self-destructive. You may be the best in your domain, but it doesn't necessarily mean that you're the best and most profitable option for an employer.

Perhaps it was a little too strong, apologies. I've just had this conversation far too many times and much of the opposition to unionisation is of the ridiculously simplistic 'why don't you just leave and find a different job?' kind.

The fact that they aren't, for one thing. This is a delusional worldview - most people in employment, regardless of their industry, do not have the time or necessary capital to fund their own business venture.

Yes - despite the bleating about unions from people who I can only assume have never had to fight exploitation and unfair practices, unions are one of the only ways that you as an employee can adequately defend yourself from bad employers AND bad employees.

Yes, software developers are generally paid well and if you can earn the respect of your peers, you're usually treated pretty well too. However, the industry is rife with horror stories about sexism, over-working, burnout, family disruption, harassment and abuse - not to mention the ridiculous burdens placed on developers who are also expected to be on call 24/7, manage the company's IT infrastructure, and generally do whatever the hell their superior demands at a moment's notice.

For a privileged segment of the industry, there is no problem - but that is by no means representative of the whole. Software mills churn out shitty software and treat their employees with the same respect they give to quality and professionalism.

Being part of a union gives you the numbers required to do meaningful damage to a company which doesn't treat you right. As always, a balance must be struck between the strength of the employer and the strength of the union(s), but for many in this industry, it's currently a losing battle. More and more demands every year, but fuck you if you want to be treated better.

Don't delude yourselves into thinking that being part of a union is only about money. If you ever have to work ridiculous hours, not see your kids or your partner, suffer from lack of sleep, do things outside of your job spec, and generally just feel like you're being taken advantage of, then the reason for this is that YOU ARE INTERCHANGEABLE. You're not a special little snowflake just because you're pretty darn up to date with the latest technical shizzle-wizzle you read about on HN. You may be technically very proficient, but then so are a lot of your peers, and there's no shortage of developers out there.

This may be a highly skilled industry, but it's also one with a very low barrier to entry and a shit-load of people producing OK work at a fraction of the cost of your salary. You're not immune to abuse just because you're good at what you do.

This doesn't even make sense. Andy's insight was nothing to do with programming or software development - he identified a flaw in the proposed design and suggested a better solution. That's not coding, and it's not specifically related to software development either. 'Software Development' is rarely done in isolation, and often requires teams of people with different skill-sets. Some will be excellent at estimating effort, others will be great at identifying product flaws and fixing them.

Look at it this way - I wouldn't want to walk over a bridge built by somebody who has no engineering skills but can paint.

Oh, and my 2 cents - programming is part science, part art. It's neither one or the other.

Isn't this simply trading one level of complexity for another?

Maybe the OP is just giving a bad example, or maybe I'm missing something - but one thing I really don't like in his example is that model B's 'waitFor' call needs to know about Model A, and that model A has an appDispatch. This kind of tightly coupled code isn't going to do anything useful for your codebase if you have a large application. It might make debugging easier right now because things are more explicit, but it will make you less flexible in the long term. It also doesn't solve the problem that you still need to understand that A has to finish before B can start - which I suppose most people would simply solve with an additional event. The OP does mention this in the article, but I'm not convinced that the trade off is worth it here. If I'm to explicitly state dependencies within the event handling code, then that means that any time I want to change how things handle events, I've got to remember exactly which of my dependents reference me. This isn't helpful - and in fact it may be more painful than the current situation.

I guess my main problem here is that the benefits this brings just aren't enough (in my view) to offset the potential pain. To me, it kinda just feels like cutting off your nose to spite your face. You might make one area a bit easier to debug, but you lose out in other areas too.

On the surface the code may look more sensible and easier to think about, but in practicality I'm not convinced that this won't introduce additional pain later on.

Easy - he doesn't support anybody else's requirements, app designs, or coding practices.

Honestly, I don't think this trademark should ever have been granted in the first place. It's definitely way too common.

Your problem is that you're making some absolutely incredible claims without any evidence to back them up. Prove to me that your product does what you're saying it does, and then maybe I'll trust you. How does it work? Why do you believe that your solution is effective? What guarantees do you provide?

At the end of the day, HN is full of very technically minded people, including security experts, programmers, and researchers. You're not going to be able to sell to these people without seriously backing up your claims.

In my experience, a pay-rise is rare unless there is direct pressure from you, or the company believes that they'd be worse off if you were given a better offer elsewhere.

If you have no leverage, then it's not in the company's interests to pay you any more money. It sounds like you've at least queried the lack of a pay-rise, so some options might be:

1: Demand a pay-rise outright. You're being asked to take on more responsibility and accountability with a 'promotion'. It's only fair that your greater sacrifice is rewarded with greater compensation.

2: Negotiate terms of your new contract - additional benefits, or a guaranteed pay-rise after x amount of time, or something else you'd like.

3: Find an external offer, then use that as a negotiating tool. If they really want to keep you, they'll find a way to strike a deal. If not, then at least you can move elsewhere.

Basically this argument that 'you're 100% at your current level, but only 85% at the next level' is bollocks. If the new role is more responsibility, more accountability, and generally more demanding and difficult to do well, then that should be reflected in the compensation. No ifs or buts - anything else is simply taking advantage of people.

A lot can happen in a year - particularly the stresses of taking on more responsibility and having to be more accountable - do they really think it's fair that you should be forced to do this for no extra pay? In a year, what's stopping them 'promoting' you again to an even more difficult job but where you're only at '50% of the benchmark'?

It's a load of horse-shit.

True - but you can add an additional layer of security to the password reset request if this is a concern, such as personal questions.

Changing internal functions is not considered a "breaking change" by anyone I know.

If changing internal functions results in breakages, then I don't know what else you'd call it except a breaking change.

You're allowed to refactor code internally, which definitely includes changing the structure of the internal functions.

If the person changing the function doesn't then go and update all of the callers, then that person isn't doing their job properly. It's not refactoring if you just randomly decide to modify a single function's signature and then don't follow up and fix the rest of the code.

Other coders who are also working inside the same module/API boundary will have their edits broken by this change. The original developer cannot fix their code because it's not checked in yet.

Not if you're making small commits, often. Changing a function signature necessitates the modification of all callers to that function. This would be a large commit which includes all of necessary changes to ensure that the software remains in a stable state.

I already explained why they can't follow up - because the code that needs the follow up is in their codevelopers' working trees. Flagging here would be silly. Almost every single commit would be "flagged for fixing breakage", since every single commit can refactor/change internal function signatures.

This is still just a process problem - if you committed and merged more often, these issues wouldn't arise. The reason you're having these issues is because you're allowing your working trees to become too out of sync. If everybody is working on the same module, then those developers should be trying to retain lock-step. Even if developer A (the breaker) doesn't have access to the code of developer B and therefore can't update his function calls - committing smaller changesets and merging more often, where the overhead in assessing changes is tiny, will wipe out 99% of these issues. If you can't see the forest for the trees, then issues are going to slip through.

Yes, and we are all human so sometimes, despite heroic efforts, we will all make stupid mistakes as well as subtle mistakes. Now, once we made the mistake, do we want our tool to insidiously hide this mistake from us, making it as expensive as possible to punish us for our mistake? Or do we want a tool that tells me ASAP "Hey dude, you made a stupid mistake over there"?

Except in JS, the code itself isn't a mistake. It's your problem - JS has nothing to do with ensuring that you keep your codebase bug-free.

And to do this job, I have tools like languages that help me find those mistakes quickly.

Then use them, and stop complaining about something that you don't even use.

Making mistakes isn't "sloppiness", it's human.

Making the same mistake repeatedly and then blaming your tools is sloppiness however you dress it up.

If one language makes writing a non-shitty codebase harder than a different language, it is also the fault of that language.

It's not harder, it's just different. If you learn the language and its subtleties, then you won't have these problems.

So basically you need to use strict ownership at API boundaries as that is the only way to avoid this. This isn't always optimal. It sounds like you're sacrificing quite a few goats at the js altar for no real benefit.

No, but when somebody I'm working with makes a potentially breaking change to a shared codebase, they either ensure that they also fix the now broken code, or they flag it up to the people whose responsibility that is. Aside from that - most people simply avoid making a breaking change - or if it absolutely must be made, then a process is followed.

Your question about why a developer would need to change an internal function's signature is ridiculous

I wasn't asking why the developer was changing a function signature - rather why they're so eager to change a function signature without following up and either fixing the things they break, or flagging those things up to the people who require it.

This isn't a necessary fact of life. Even most sane dynamic language will error out when such incompatibility arises, instead of blaming the developer for using a process incompatible with the js way.

There's no such thing as a random error. If there's an error, somebody made a mistake. Some mistakes are stupid, others are subtle. Changing a method signature and then not doing something about the callers is a stupid mistake.

Not to mention the other argument, that with all the discipline in the world, humans will still make mistakes. Instead of translating to errors, they translate to bugs.

Of course humans will make errors - but your job is to minimise the frequency and severity of those errors. There's no excuse for sloppiness - you either keep on top of shit, or you don't. Call it whatever you like, but a shitty broken codebase is only the fault of the developers, not the language.