Low level devs have always been thirsty. How do you think they got so good? It certainly wasn't by hanging out with models.

It moves extremely fast. HTML, CSS, and JS are living standards now, updated every year. Browsers are updated constantly. Frameworks, tools, methodologies, etc can all go from hot to not in a year, easily. So, the platform, the environment, the tools, the languages, and frameworks, and the trends all change constantly. It's a never ending fight to keep up. You could write a new project every 6 months using a completely different stack.

No it's not. Certainly not for scrum. The scrum guide is short and easy to read, how do people consistently get it wrong so badly? - http://www.scrumguides.org/scrum-guide.html

The whole article is one giant "look at this privilege, we need safe spaces" piece of crap.

Not only does this tell others that it is not OK to be disrespectful, it may also give the original commenter a chance to apologies and change his/her behaviour.

I hope someone in the comments goes off on him for spelling "apologize" wrong. (Though I suppose the Brits spell it with an "s", which would still make it - "apologise".)

Do you know what the proper response to someone not appreciating your free software is? "FUCK OFF." If they're right, and there is an issue, make a new issue that only includes technical details and tell them to fuck off in theirs and close it. Done. There always have been, and always will be, asshats in the world.

I know people that used it and they only had good things to say about it. Also, if they still do it, the setup where you only pay for the bandwidth you use is pretty cool.

Depends on what you do. If you're doing web dev you'll be lucky to make it 18 months.

I feel like I see all of those issues with self-taught devs. Wtf schools are you hiring from? Proper 4-year degrees or code camps? All of those issues are addressed in a good 4 year program.

I do agree about their growth though. Good devs will learn and get better pretty quickly. You show them something once or twice and they get it. Other people can get their hand held for months and never go anywhere. You're showing them the same things over and over. Programming isn't for them.

Disabled how? There's NVDA for the blind.

Reminder to everyone - EFF is an option in the amazon smile program. You can shop at smile.amazon.com and select EFF as your charity and it costs you absolutely nothing to donate to the EFF via purchases you would make anyway.

And it's infuriating. Not only are they making what you make, they are holding the company back. When I worked at a place that provided bonuses to everyone based on the company's performance, that kind of person would have killed everyone's chances for a bonus.

Linq is the new the Perl regex. Write once, struggle to read for years after.

The thing about programming is that in a proper shop there's zero room for emotional arguments and ego. Facts rule everything. You think your plan is better? Then you'd better have hard numbers or some seriously solid reasoning to justify using it over someone else's method. I'm not saying women are incapable of this, but they tend to make emotional arguments. Those simply will not fly when you're talking about compiler optimization, database scaling, host replication, etc.

Having said that, I've worked with some great women in the industry and they've understood this. I have a feeling that the same people that are making emotional pleas for "more women in STEM" would not understand this.

Visual Studio Code is also free. So is Atom. A lot of people use the free version of Sublime.

Development in general has gotten kind of awful. Docs for everything always seem to be out of date. If you're doing web development your life is spent trying to figure out whether the docs are wrong or whether you're doing it wrong or whether that random post on stack overflow from a year ago is wrong.

Don't even get me started on ancient locked threads on SO that only apply to old versions of something and every time someone asks about a new version their question is just marked as a dupe and trashed.

Regardless, it seems that this dev's final straw was that Microsoft wouldn't push their app because it competed with Microsoft's own app. Now they're jumping over to Apple? Have they never heard of the problems devs on iOS have had with Apple stealing their app's functionality and then removing them from the marketplace? All of these walled gardens suck.

A lot of what you're talking about has nothing to do with SCRUM or Agile. E.g. - Whether the code that a team creates is understandable and maintainable. If you don't understand why abstraction is valuable I question your understanding of development in general. I'm not saying this to belittle you but to inform others that are reading what you're writing and taking it as gospel.

SCRUM/Agile are just tools. Like any tool, they can be misused by morons and you'll end up with poor results. I've worked on teams small and large on SCRUM and waterfall projects alike and I have seen SCRUM be very successful when properly implemented.

As to your comparison contest - One person will always out-code a team if that team is composed of poor developers. Even if there are 50% rock stars and 50% idiots the team will still lose. The good devs will spend all of their time cleaning up after the bad devs. This is why some companies are extremely aggressive about hiring "the best". Bad developers aren't just slow, they are cancer. They actively hinder the rest of the team's progress.

TL;DR - If your life is crap it's because you are stuck with crap management and crap devs. Find a new place to work and pray that things are better there (spoiler: they probably won't be).

This is how companies sink. Rather than spend a little now, they allow it to go on until it's so bad that the only apparent answer is "rewrite". So they get a loan or throw the last of their cash at the problem but mismanage the rewrite as well. Then the whole thing just disappears into the inky depths of the ocean.

Well yeah, it takes effort to do something properly. When you're running in zero-fucks-given mode, you're going to write crap.

Ugh Unity. My first time in Unity I couldn't believe that you couldn't use getters/setters for properties and still have the integrated UI support for your custom properties on your object.

Also, all of the upvotes to you. Gaming has turned in to the movie industry - generic crap from huge companies makes all of the money. Indies try desperately to break even while making the thing that they think is actually cool.

You just have to break down the multitasking paradigm into a childlike example they can understand - Is it faster for me to cut one board and nail it in place and then drive across town and do the same on another house and then return to the original site and do one more board and so on until I'm done? Or is it faster for me to just frame out one house and then go frame the next one without wasting hours driving every day? Those hours of driving every day are context switching and it kills flow, which is what you need to work efficiently.

Looks really cool. I glanced through their explanation of how it works and I'm still not sure how versioning works with respect to providing version-specific instances of the docs that apply to a particular language/framework/whatever.

Time to submit a PR to make it "CrackerList".

I agree. I recently had to decide this for myself and decided to err on the side of DRY. I decided that abstracting my tests made way more sense with respect to maintaining them than some concern about others using them to understand the API. That's what proper documentation and code examples are for. The ability for some tests to double as examples is handy but it shouldn't be done at the expense of maintainable test code.

Which is how it's meant to be used. It's not even, strictly speaking, a software development process. It's just a process for producing just about anything where incremental design improvements are possible. You could apply SCRUM to other things as well.

Thanks for pointing this out.

Yeah, I think calling cutting & pasting html into a wordpress blog "programming" is more than a stretch.

This is the best advice because you're the most likely to be solo. Anything else and you're going to end up on a team. If you're part of a team and you're working on good sized projects, you're inevitably going to end up building and using your own frameworks/utilities. It's stupid to keep doing things over and over. DRY is one of the most fundamental facets of programming. Yes it limits creativity but it does that in order to improve productivity and consistency. The name of the game is make money, not have fun.

Not just lacking knowledge, but he himself is the sole determiner of what constitutes the knowledge necessary to be a good frontend dev! It sounds like he did well on at least a few of the interviews but still didn't get hired. Honestly, based on what I've seen of his personality in that post, I wouldn't want to work with him either.

The complexity of front end work is determined by your level of seniority and what kind of work the company does. I've written entire validation frameworks for the front end. The work ended up being pretty complex. I don't think it's unreasonable to expect front end devs to have some basic algorithm knowledge. A depth first traversal is trivial, you do that kind of thing regularly.

Even so, interviews aren't just a test of knowledge, but of personality. It's about learning - How does this person approach problems they're unfamiliar with? How will they respond when they don't have the answer memorized? I'd rather watch someone struggle to think something through and then finally admit - "I'm not really sure, I think I'm close but I'd have to ask around or do some googling at this point." Rather than throw their hands up and whine about algorithm questions in front end interviews. No one is going to hire the latter.

Seriously, I got to that part and had to stop reading. This guy is a huge baby. How you write it is IN THE NAME. I haven't taken algorithms in forever either but you do this kind of stuff all the time. You need to look through an object tree for something, you're generally going to end up either going breadth first or depth first. This isn't something you do every day but I'd say I do it once a month.

No one cares because they continue to profit without fixing the problems. Today's computer bugs were yesterday's lax safety standards. They were lax because it was expedient and cheap. Companies didn't care about workers losing an arm here or a leg there because overall, they made more money by allowing it. Software quality issues are the exact same thing. Testing costs money, good developers cost money, well done requirements analysis costs money, you get the idea. So, leadership instructs workers to do whatever the minimum is to still get paid and chalk the rest up as "amazing savings" and give themselves a bonus.

I've seen this as well. Their code is so terrible, their management so lousy, that any experienced person will just leave. After the first week they're already looking for a new job. High turnover and loads of juniors is a big red flag.

Oh that's easy. Disguise your request for feedback as a question on SO and then sit back and watch the criticism pour in.

I've heard the cutoff is something like 50 hours a week. The obvious problem with that though is that you can't work two jobs with 50 hours/week.

The stress and pressure is high, you end up working 12+ hour days because any amount of time not working just makes you feel like you are failing yourself

Unfortunately I feel like this is practically unavoidable. I've kept my day job and ended up in the same scenario as you - 12+ hour days only you're at least getting paid for 8 of them. I'm not doing it now, but when I was, it was exhausting. You feel guilty for having a weekend. You try to pace yourself but the mountain of work before you is gigantic and if you're on your own, you know that you're the only one that can chip away at it. Even with a partner I've struggled with this problem.

/u/captbrogers already mentioned one part but I'm replying here so you'll see it...

Definitely look into area user groups (MeetUp usually has a bunch). This is an amazing place to network. There will be recruiters. There will be hiring managers there that are networking. There will also be other devs there who may just happen to know about open positions at their companies. I've even seen people advertise open positions at their employer during these meetings. Worst case, you'll learn about something new/cool if it's a good group.

Just being at that group can give you a foot in the door. You're spending your free time learning more about development, and that's a good thing to see in a potential hire. Also, there's nothing wrong with going through a recruiter to get a job. It can be kind of annoying at times but it's a lot better than being unemployed. If you do that go route, make sure you work with a technical recruiter. A generic one is going to be absolutely useless at finding you jobs you're qualified for or would be interested in.

Choo Choo. That's me tooting my own horn. I called it. Microsoft is well on its way to using its classic embrace, extend, extinguish technique against Linux. It's never considered Linux a threat until now; when people are really and truly finding the Windows experience to be so terrible that it makes learning about an entirely new OS appealing. If you're a Linux contributor, do everything you can to keep all of that Microsoft garbage out.

I worked on a small team and wrote a tool in Java that maintained, aggregated and indexed a collection of files.

Biggest lesson learned? Bad programmers write bad code and sometimes it's not even salvageable. People like to whine about people like JoelOnSoftware telling managers to only hire rock stars but bad code is a nightmare to deal with. In this case I gave up and rewrote about 1/3 of the application myself out of desperation. I certainly wasn't a rock star at that point (still not) but at least I knew wtf I was doing.

I've run into similar situations since then with basically the same end result - having to entirely rewrite their code. In the most recent instance there were race conditions, no comments, the same variable would be used for multiple things (which frequently didn't match the name of the var), magic strings, magic numbers, long and inexplicable string manipulation blocks, they violated some of the most basic best practices... the whole thing was garbage.

Lesson: Don't be a half-assed developer. Everyone else you ever work with will hate you. You don't have to be a total rock star, but know what you're doing, and if you don't, ask someone else.

MMM is important if you plan on actually getting a job as a dev. You are frequently being managed by people that are not technical. They will (un)knowingly take advantage of you and you'll end up writing garbage code and working long hours. I see this happen to juniors all the time because they don't stand up for themselves. Sometimes they're smart enough to ask a senior to step-in on their behalf but I see them get run over all the time.

Like you said, exceptions are basically a GoTo statement. And as such they typically ruin any kind of optimization / predictive instruction loading. I definitely avoid using them when I can. For the most part I leave them for developer errors. Things that are meant to be fixed by developers/in development. Like ArgumentOutOfBounds. If it's supposed to end up on the UI then it shouldn't be an exception.

Github itself went full retard last summer. It's not just individual users.

Some frameworks are massive. Understanding their intricacies can be as essential as understanding basic algorithms. I've worked with new people that know the frameworks and with new people that don't. It's a lot easier to on board the people that are already familiar with them.

I'd never considered that, but it makes sense. I did spend my teen years programming on my own. Reading everything I could find, taking any classes I could. I loved it.

Oh, so you're getting the real University experience then! Thankfully nearly all of my CS instructors were native speakers. Sadly that was not the case for science/math, so I understand your frustration.

I think that problem permeates all of SE today. No one wants to get a CS degree or put in the equivalent thousands of hours on their own to have the same basic understanding of algorithms, data structures, etc. They just want to "learn to program" and get a 6 figure job. I hate working with these people. Their code is abysmal. Even if they do manage to learn that something is a best practice, they never learn why. Which makes them incapable of distinguishing real best practices from horrible ideas posted on blogs by other idiots.

You encounter this in other facets of development as well - project management, bug tracking, testing, and user experience. It's rampant.

I was ready to downvote blogspam but that was actually pretty good. Great infographic too. I'm tempted to say it should even go in the sidebar. There are always people asking, "what language should I learn" and this would be a nice way to answer all of those.

This is not a problem with overloading. This is not a question of performance vs security. This is the person that originally wrote Buffer writing a poor API.

For one thing, it doesn't make sense for every type except Number to result in getting enough memory to hold that thing. Why are you assuming that I'm never going to just want memory to store a number? Writing an API like this in JS where the caller is responsible for handling type issues is fundamentally stupid. When you write an API in JS you do your own, internal typechecking and any other input verification necessary and then you handle the errors yourself. This is just a basic part of writing something that's self-contained. Even in a typed language you still have scenarios where you have to do this - E.g. What do I do when you pass me an array and there are no items in the array but at least one is required for this function?

OP - Your title sucks but it's a good issue to know about. So, thanks?

I ditched GitHub after the meritocracy/CoC stupidity as well. No regrets.

Well 6 months ago they disabled a repository for using the word "retard". The whole company's ethos has changed. They removed the meritocracy and replaced it with SJW garbage. That's just GitHub itself. Individual projects are being hammered by asshats trying to get them to adopt some insane SJW code of conduct. Like software cares about any of that garbage.

I would read that in code without a second thought. Some of my coworkers' expletive laced comments on the other hand... those sometimes had me wondering how much they'd had to drink and how late they'd stayed up when they wrote them.

People with no heads, you monster! Think of the Headless Horseman and stop being so discriminatory!

Murdoch's response for the lazy -

The second was a set of emails from Duncan Murdoch, President of the R Foundation and an R Core member, in which he dismissed my "bug report" (note the skeptical scare quotes he put on it) "about some variable name that you find offensive is clearly an example of nothing more than shit-disturbing" and stated that myself, and those who had commented in favour of changing it, were no longer welcome to participate in R's bug-tracker.

I can understand how one might paint that as an overreaction, but considering the kind of garbage that's happened over on GitHub I completely agree. If you want a professional environment, then behave professionally. Don't go looking for reasons to take offense to things and then derail the whole project because you're too immature to handle standard programming nomenclature. There is work to be done, no one is interested in your imaginary problems.

Data Structures 101 - Many structures have heads and tails. E.g. Linked Lists have a head and a tail. When you write one as a structure you write things like "getHead" and no one bats an eye because that's what the function does. I don't recall anyone in my CS courses even giggling at this stuff and we were still teenagers at the time. Is this guy 12?

Any UX site whose mobile experience sucks loses all of my respect. Scrolling is nearly broken for me in Firefox on their site.

Money is appreciation for your work. If they had no appreciation for your work, you wouldn't get paid nearly as much, if at all. Not being "appreciated" isn't a programming thing, it's a corporate America thing. You exist to make the company more money than you cost. They appreciate you to the extent you're able to do that. Cost 100k and single-handedly make the company a million? You'll probably get a pat on the back. Not doing that? Then corporate America doesn't care. That's just the way it is.

For those wondering -

The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

I'd be concerned about the quality of questions over in the generic one. May I suggest opening your AMA a few hours early to get questions trickling in and upvoated/downvoated accordingly before you actually start? The programming/IT communities aren't huge and it'd give more people a chance to get questions in before you start.

Also, thanks for doing this, I'm looking forward to it!

Edit: one more thought - the mods may be willing to sticky your post for the day as well, which would help.

You're not a programmer. Don't make ridiculous claims when you have no idea wtf you're talking about.

A career? Not really. You'll only get hired at places that don't do any sort of technical interview (which are already awful). As soon as people catch on you're going to get fired because your code is the equivalent of AIDS.

There are repositories and there are standards. Those are called frameworks, sometimes components or libraries. People use them all the time. You can still get into trouble with those, but it's significantly different from just cutting & pasting random crap from the Internet.

Real programmers do not like those people. I have seen code like this and it is absolutely abysmal. They don't know enough in the first place to know what's worth copying so they just copy whatever appears to work based on some blog post. Then you inevitably get in there to fix it and can't understand why on earth they would be doing it that way. Then you realize, this code looks nothing like their other code. You slap a snippet into google and... there's your answer. They just cut & paste garbage from someplace without even understanding its purpose. Amazingly horrible code. If you do this, your coworkers will despise you.

Grabbing snippets to run a SQL query != mashing together snippets to create production code.

Your confusion about the languages in .NET isn't exactly encouraging. No offense, but PHP is kind of the lowest of the low when it comes to programming. It sounds like you need to invest some time in educating yourself about Java/.NET before you just try to jump into a job with either of those. Otherwise the interview will probably be kind of embarrassing. If those languages are too challenging or different, consider doing more research into front-end languages/frameworks and get a job somewhere doing that (HTML/CSS/JS).

A portfolio isn't sufficient. I don't have time to figure out if you actually wrote the code in your portfolio. Even if I've narrowed down the applicant pool to five, I'm not going to go through all of your repos and start googling snippets to see if you just pulled half of this thing from someone else. So, no, a portfolio of any kind doesn't prove you can code. It's certainly nice to see because it gives me things I can ask you about during the interview, but it's not proof.

Having said that, I have found that presenting people with a complex snippet and asking them what it does is just as effective as any code test. It takes much less time, there's a lot less pressure because they aren't coding in front of you, and honestly, we all spend a lot more time reading code than writing it. It also gives them a chance to talk about anything they would do differently to improve the code.

Unless the language/framework is really new, I don't even put how many years experience I have with something. I just tell you all of the things I have experience with. I'm not applying unless I think I'm a fit. If you have a problem with my technical expertise it should come out during the interview. If it doesn't, don't blame me for your horrible interviewing standards. Like OP said, I may be rusty with a few things on there but I'll ramp up again quickly.

It melted my brain that anyone tolerated those idiotic off-topic discussions in github projects. You want to bitch about the people participating in this project? Go somewhere else and do it. The issue tracking system isn't there so that you can whine like a baby.

Programming has never been a hugbox and I hate anyone that tries to make it into one. Programming is essentially math, and math is brutal in its honesty. A solution works, or it doesn't. One algorithm is faster than another. One query uses less memory than another. There are objective ways to measure these things. We don't need people introducing any sort of "feeling" garbage into Computer Science.

Github lost all of my respect when they adopted that stupid policy. I'm on BitBucket now and IME so far it's got better tools and better rates anyway.

The big question for me is: What kind of documentation are we talking about? Are these API docs? Are these guidance docs for things like UI or architectural design? Are these docs intended for end-users for using the application (like help docs)? There are a lot of very different kinds of docs with very different audiences. It's unlikely that a single person would be qualified to handle all of these. So, what kind are you talking about?

There's going to be a lot of judging going on based on your username...

Are SJWs actually building a secret Aryan Nation and we just don't know it?

It's embarrassing and infuriating. This is computer science. There is a long history of people using vehement, expletive laced comments to state their opinion regarding the design or implementation of something. These are attacks on ideas, not gender or race or some other crap. No one reads code and thinks, "Fah! I bet some transgender black woman wrote this." Because they don't care who wrote that code, it's just bloody garbage and they don't want to see that crap again. Maybe if it's particularly egregious they'll hunt them down in rev control and tell them to stop committing horrible code. Even then, it still won't be about anything other than the code. Devs only care about code. I don't care if you're the next Hitler or the next Gandhi. If you write good code, please contribute, if you write horrible code, gtfo.

The best part is that immediately below that it says -

we seek to treat everyone both as fairly and equally as possible.

...unless you're white or male. In which case it's actually impossible for you to experience any kind of harassment or prejudice. Because that's "reverse -ism". The hypocrisy just from one paragraph to the next is amazing.

Thank you for your kind words!

That's because BitBucket is a part of a suite of tools made for professionals by Atlassian. They leave the hipster garbage out of it and neutrally sell products to other businesses. Which is the way it ought to be. I've used ~5 of their products and I like all of them. BitBucket included. 5 free users and unlimited repos for closed projects is amazing. No one else has anything like that. You can actually have a small team and get started on BitBucket before you've got the money to expand.

They aren't thinking. Logic has no place in their brains. I don't even know how they're capable of programming because logic is such a foreign concept to them.

Edit: If A, then B. Unless B doesn't really feel like being controlled by the patriarchy of A. What makes A so much better than B anyway? B can do whatever it wants!

I'd laughed and moved on as well. You made me take a second look.

Wow. Why didn't the maintainers of the project just close the thread as off-topic and move on? The world is full of bigots and they contribute to many, many projects. Are we going to create a whole new selection process of "pure" people who are qualified to make code contributions? Perhaps we could even have a name for them. How does Aryan sound? Heck, maybe we could even systematically get rid of everyone that doesn't qualify to be a part of our new, pure group of people that are good enough to contribute to projects on Github.

I get the sense that these people have never even had a real job before. Have they never encountered the office lech? The office racist? They nearly always exist and guess what - you work with them anyway. Because that's what you're paid to do. And maybe, if you're lucky, during the course of your working relationship, you can gently steer them onto a better course. Or maybe they're just hopelessly ignorant. Either way, you work with them because you're an adult and this isn't 1st grade. You can't avoid people with "cooties".

God forbid we use a universally understood analogy when naming a piece of technology. People are such idiots. Unreal.

I am also on the BitBucket train. I looked at about 10 other options before I chose it. So far I've been mostly impressed -

Choice of Git or Hg. 5 team members and unlimited repos for closed projects. Adding more members is relatively cheap in comparison to other hosted options. Integration with other Atlassian tools.

One thing to be aware of - there's a strange bug when you create a new, empty repo via their web interface and then try to commit to it via SourceTree (their free source control program) - it fails. I don't remember all the details, its been a while since I made a new repo, but just something to watch out for if you're new. There are workarounds to be found via google. (You could always just fork a repo with at least one commit and then just strip the history as well.)

sigh, sadly IE actually allows you to prevent sites from downloading any custom fonts whatsoever. (Specifically because of a bug very similar to this that was encountered a few years back). This is a nightmare for web devs. We have things like icon fonts, so when you don't load the font there are no icons on the whole site. Buttons that are just icons? Blank. Super fun.

I worked mostly at night in college. At my day job I switched to mornings because no one hassles you for showing up early and leaving early, but you still get a few quiet hours in the morning before other people show up.

It's funny to see people still posting about this. It's been so well known for so long. One of JoelOnSoftware's biggest rants is about this topic all the way back in 2000. Yet, sadly, managers continually ignore and pretend like it's not true. Managers that were once programmers themselves somehow manage to flush this simple truth from their brains. It's awful.

My work is constantly pushing group-wide IM. I don't want to be on group-wide IM. 95% of them aren't going to be useful or apply to me. It'll just be constantly bothering me and ruining my focus. The few times I've tried using it I've last about 20 minutes before closing it.

You get an upvoat for testing your backups.

"We ignored standard security practices because we knew better." Always results in a good story.

Sooo many awful memories. Among them - IE's horrible stylesheet limits (exhibit A) (exhibit B).

You're doing your best to keep your massive web app modular and you're using different stylesheets for all kinds of controls and modules. One day, some of your styling isn't working. But it's different pieces in different areas that aren't being applied. There's no rhyme or reason to it. Finally you start just mashing styles from one file into another and... behold, it works. So... then you decide aww man, this bug is a nightmare. We have sooo many files. Okay, we'll get around it by just mashing all of them together and serving up a single CSS file. NOPE, there's a limit to the number of rules you can have in a file... and file size too. It's SO fun. So, then you get to spend your time guessing and checking and tinkering until you've found the magic balance between number of files, number of rules, and size of files that makes IE happy.

...and people wonder why Devs hate IE so much that Microsoft is changing the name.

It's just refreshing to see a piece that's truly objective. So much of programming feels like an infomercial these days - EVERYTHING YOU KNOW ABOUT ARCHITECTURE IS WRONG, DO THIS!! I mean, there's always been some element of that, but I feel like web development makes it a weekly thing.

I really enjoyed this author's honest pro/con approach that encourages the reader to determine which direction is best for them on their own project.

Informative and objective, I like it!