I think there's something to this - there's a plethora of websites sprouting up using the 'Hacker News for ___'. The semi-casual-professional platform makes sense for most industries.
I work in arts/film, and although it probably wouldn't work for us, I'd love to see it done.
I traditionally come here for the non-technical stuff so it'd be a great way to get specific. Otherwise, there are news sites which allow the user to deselect certain subject matter and leave the rest. Also an option.
I'm running http://www.trejdify.com/ which is like HN but with business news only, and I have a modified spam-filter that sorts the articles automatically in the different categories. Maybe HN needs something similar?
Are people misusing the system as in do they add all tags available to get more traffic? I saw one who added these tags to one link: "assembly c compsci go java lisp lua php python scala"
The more tags post has, the less people will see it because users have an option to hide posts with certain tags. And of course moderators are there to adjust the tags if necessary.
The site is pretty much dead anyways. Note how there is only one story on the frontpage atm with a single comment. But the code is somewhere in github if you want to make your own.
And yet, it's a forum and to a degree, also a link aggregator. If it's only purpose was to promote YC, only YC members would have accounts, but people already discuss all kinds of things here, not all of which directly relate to Y Combinator.
People keep complaining as the site grows that the content no longer reflects their particular views. To me, there are two possible solutions to this, or three, if you count "just ignore it": enforcing a more narrow definition of what can and can't be posted, or else smarter filtering of content.
I agree. But, the purpose is to promote YC. It may have started as something else, but this website is more powerful than a lot of big name news outlets. Money is made here, believe it or not. That is why a change in the formula is not something that may happen. Why change something that is already helping YC make lots of money?
I can certainly see how, if it's working, they might not want to 'fix' it. But... users who feel better served by the content they get here might be more inclined to stick around, participate, become involved and eventually apply. Each of these "hacker news for x" sites that pop up are clearly attempts to exploit what appear to be gaps in what Hacker News provides, and maybe by extension they're taking a bit of the focus off YCombinator itself. Apps like hnnotify are providing functionality that could be added to the site.
Just because it happens to be making money now doesn't necessarily mean some aspect of the design isn't keeping them from making even more money.
The morphology of the site must in some way shape the interaction between users, and by extension the way they perceive the community as a whole. Different decisions both in policy and in design would lead to at least subtle differences in what Hacker News is.
But i'm not confident that adding a feature to organize the posts a bit more necessarily undermines something fundamental about the nature of HN. Nor do I think the only thing keeping this place civil is pg keeping his thumb on the ban button.
Aren't they both asking "What technology has been relevant for the past 5 years?" Maybe I just need an example that answers one question but not the other?
fair enough but I'm fairly sure that if you traveled in time from 5y ago with a decent developer from that time he would have hard time landing a job today
Some people have an easy time programming, and the specifics - libraries, languages, etc - don't matter at all. They'll pick up that new stuff in their sleep.
I recently hired a Java guy after talking to him - he had all the right hallmarks so I was pretty sure he would be good. I gave him a task with a piece of software I am intimately familiar with. A good developer would have had to get up to gear for a week (40 hours), then code, test, work around the little kinks (there are many).
All in all an optimistic assumption of mine would be that this task would take a brand new guy a month. The dev I hired did it in less than a week!
These people are rare. They are the rockstar programmers. And if you find one, you want to hold on to them no matter what.
Team players? What if the guy can do twice as much in a week than a "team" of 5 mediocre guys?
To get back to your assertion, he then proceeded to learn Android and put a functioning app in the Google play store in less than a week.
Granted that's still Java, but the libraries are all different and developing for mobile is also different.
If I had an iOS job right now, this guy would get it, despite never having done iOS. He'd learn this in his spare time and then proceed to run circles around people who've been at it for years.
The notion of a rockstar is silly. I think it's somewhat common to find developers that can pickup languages in a short space of time. Once you understand the concepts of OO/procedural and functional paradigms something would be wrong if you couldn't pick up a new language in a day (plus some more time for best practices, patterns, etc.).
Greenfield development is always easier than having to work with 200K LOC codebase that is crappy for all intents and purposes. Let's see how quickly a developer can jump on, wrap his/her around everything, then make significant changes and maybe I'll believe in that nonsense.
Personally I think if a job ad includes the word rockstar, I would expect hot groupies and coke on the job (2 or 3 times a week to allow some time for actual work :)).
In my experience you couldn't be more wrong. I've been programming for over 12 years and started out with C and C++. I have successfully walked into jobs using other 'modern' technologies with only a few days worth of learning them. Sure, things change but it doesn't take much to keep up with those changes and a lot of what's considered new by all the cool kids is actually the same old stuff in a shinier package.
> The changes in programming are pretty superficial.
In mainstream programming. You don't need to time-travel to experience huge cultural and technological shifts - you can go from Prolog to Forth to Racket to Smalltalk to OCaml to Haskell and experience more of a change than a C++ programmer from 1985 would if transported to 2013.
Inside one paradigm the changes are necessarily iterative and slow. Differences across the paradigms are huge. At a given time only one or two paradigms are mainstream, and they change rarely. The same goes for hardware architectures. This makes it look like programming is stagnant, and for the most part it is. However, when the change comes - like from unstructured to structured programming or from 16 to 32 bits architectures - people who lived happily inside the main paradigm have a hard time adjusting.
I don't know when the next major shift in paradigms will come, but it will, and then the belief that the only changes in programming are superficial will prove dangerous.
What I'm saying is that there were moments in a short history of programming when it was "hard for someone who programmed 5 years ago get a job today", and not because of economical reasons.
I personally remember one and it was around the transition from 16 to 32 bit architecture (for me it was in context of WinAPI vs. MSDOS programming). That seemed like everything has changed completely and people had to put a big effort to stay relevant. The same happened - from what I hear - when OO became mainstream. The same when we largely abandoned asm for higher level languages. Basically, I'm saying that there are such 5 years periods in which the above statement holds true.
Such turning points have, I think, one thing in common - new technologies, methodologies and paradigms are not created overnight, in each case the "new" was around for quite a few years before it "suddenly" replaced the "old". It was just outside of day to day work of most programmers. That's why I think it's important to be on a constant lookout for new things in programming - or even old, but different things. One day, in a matter of months, they may become dominant and make your skills largely obsolete which will make you maintain some legacy stuff for the rest of your career. It's a hyperbole of course.
Anyway, while today and 5 years back are not that different, maybe today and five years in the future will be. And then you'll have a problem getting a job until you catch on. I'm not saying how probable it is, but it happened and may happen again. Or didn't it? What is your perception of this issue?
I'm actually finding that I am using older techniques to get performance gains that my peers on other projects are not able to realize because they're blinded by the idea that the "latest and greatest compile-to-javascript language" is "the best", so therefore must be "for all cases."
I don't think so. Technology wasn't so different, especially web development. Most of the software we use today was in place. It would be behind a few releases and there were fewer libraries. But otherwise broadly similar. Any decent developer learns on the job anyway.
Our "response" to this is radical transparency. Client should be able to track the progress in almost realtime.
The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.
And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. The second part of this is a mutual understanding that scope is gospel. This means the client has a clear understanding of the end product and what problem it's going to solve, and you're going to have the same understanding. Changes to the gospel mean changes to everything else.
Obviously running a business is part philosophy. If you don't mind a customer looking over your shoulder throughout an entire project, second guessing your time usage, then sure, I can see how an hourly situation might work. I despise that, and so I've found fixed pricing to be my preferred approach (which has the apparent added benefit of being very appealing to most clients).
"And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. "
Bingo. Hourly or fixed doesn't matter here. Both will mess up the relationship because there's no value delivered in the clients eyes.
As for the micromanaging; some customers like running a daycare for adults and babysitting everyone. I prefer to not be in these relationships and in exchange be proactive with our updates.
> And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault.
How do you get around companies wanting a fixed price without knowing entirely what they want? As a freelancer I can't spend 2-3 days of meetings and spec writing only to lose the project because they preferred an agency/another supplier.
If I had clients who would pay for a 'Consulting' phase of producing a spec (which they could then send to other agencies/freelancers) then I could see this working, but those are like unicorns.
To people who build websites, scope means technical scope--the features, functionality, design, backend etc. A precise technical scope makes it easy to calculate a price.
But to people who buy websites, scope means financial scope--a "$100,000 project" vs. a "$20,000 project." They don't know precisely what they want...because they don't know what is possible. That's why they are hiring you!
So you learn as much as you can in the RFP process and propose your fixed price based on that. Unless the client or RFP is a terrible lie, you should be able to get it in the ballpark.
From there, closing the sale depends on your ability to convey that your expertise will help the client get the best possible product for this "scope" (i.e. price). If you want to cover a few more bases, you can provide some optional levels of effort for the riskiest items, or "nice to haves."
It's possible to be just as transparent and flexible under a fixed price contract. And if changes need to be made, they can still be made on a change request or contract amendment.
Because a client who is reliably paying you for days of work is worth a free hour or two now and then, and because the precedent that you will work for hours instead of days will come around to bite you in the ass later on.
This approach is great - giving small things for free, but isn't working for every clients. It's horrible for you when your customer is't paying a lot (small projects, low prices etc.). They are overdemanding, don't like your work, put a lot of changes and thinking that you should't do it for free.
