My favorite reply so far. I'm 37 and am starting to worry. I haven't run into any issues yet.
I have noticed though that experience become a liability. If you wrote JavaScript for IE 6, a lot of the optimizations and things one did to make sure things worked in IE 6 are no longer necessary. One should be ready to let go of things as soon as they aren't necessary anymore. Always keep learning and know why you do the things you do with code.
Yes. Just keep leveling up, and one day you will be an über-developer that can solve any problem by thinking about it for 2 weeks, then spend an afternoon writing a 100 line bash script.
It's funny: I was betting on WPF at the time but it seems dead now, with only some XAML knowledge transferable. Still have to do JS, but at least Angular doesn't suck too much.
Parent comment had to be qualified a bit: Never bet on anything proprietary which doesn't offer significant advantages over non-proprietary competitors.
LOL. I know guys who have worked the last 20 years on Oracle, and they'll have no trouble finding work for 20 more. The same for Visual C++. Or a whole host of other things. The world isn't as simple as GNU ideology would have you believe.
Yeah, like that article from yesterday about the Perl6 guys doubling down because in 18 months when Perl6 was done, the speaking/writing/consulting gravy train was coming...
I've always done this naturally, some days I read a blurb about some technology I used to use and realize, huh, I used to do that all the time but haven't touched it in years.
I think one of the key things is to have a passion for learning. I've always been bored doing the same thing over and over. Learning new technologies, design patterns, architectures, skills, etc is what interest me. That also, coincidentally, is what keeps me up to date and productive.
A master's degree, assuming no experience, is more like a warning signal for someone who's stayed in academics too long and has no practical skill. It's like you're hiring a really expensive junior developer if they've never built real world software under business constraints that needed to like be bug free, and scalable. It's like the code written in graduate college gave a shit about memory use, file or network i/o performance, a good ui design, or like actually doing the thing it's supposed to. Sorry, ranting due to bad experience in the past.
The thing is, more education will enable a good developer to be even better. It's doesn't seem to help a struggling developer in any shape or form. Unfortunately sometimes I get the impression that people stay in school to address a problem that can't be addressed with more classroom time and end up doubling down on a field that maybe isn't right for them.
At the very least try to intern early on and or successfully help a popular open source project before graduate school.
> The thing is, more education will enable a good developer to be even better. It's doesn't seem to help a struggling developer in any shape or form.
In my (limited) experience, the people who struggled in undergrad run screaming away from any possibility of doing grad school (my experience here is consistent across econ and CS). The people who were good at the field consider grad school because the psychic costs of learning more are low.
If you find a person with an MS who can't pass a simple programming test, then (and this is very general, I'm sure there are exceptions) take a look at the school her or she attended and stop interviewing people from that school, problem solved.
> take a look at the school her or she attended and stop interviewing people from that school, problem solved.
This is really bad advice, because much about learning programming is about an individual effort. It has little if anything to do with the school.
> If you find a person with an MS who can't pass a simple programming test
You actually need more than a simple programming test that solves a single problem. You need to see enough code to have some architecture, designed by the candidate. Interviews are too short for this so experience whether at some other company or open source, or just if skilled people can vouch for you goes a long way.
I also agree in doing a black mark against the school however it helps to have a look at (in terms of Masters, PhD) the quality of work within that department / within the graduating year. It's a way to go beyond the marketing fluff in non top-tier schools.
Replying to leobelle here since the thread got too deep.
I agree that learning to program is individual, but you don't learn to program in grad school. If a school gave you an MS and you can't do Fizzbuzz, that school isn't serving its signalling purpose (that I mentioned in my first comment). So while that school may be fine, if lax, if the employer is using education as a signal, a school that doesn't fail students doesn't provide a strong signal.
Relating to your comment about needing to see more code, education is actually perfect for that. Most companies don't let you take your source code with you, schools do. So provided you took some courses that required significant engineering projects, a student has a big pile of (hopefully) reasonably-designed code to show off to an interviewer. A person who worked for a less-than-progressive company (since some maintain open source libraries and such) does not. They both have their open source contributions.
The title takes a reasonably interesting boat and ruins it with inane link bait. Sometimes when you try to make something great look bigger than it is you've ruined it.
You're right. I was entirely fooled by the creative language in the article's title. Expectations shattered, I started drinking again after 6 months of sobriety.
Twisted is a library you might want to use if you want to write non-blocking code. So you would care a great deal if this wasn't python 3 if you wanted to use python 3.
Mercurial is an application you use to version control your source. I'm not sure I understand why any python developer would care if Mercurial was written in python 2 as long as it worked. Maybe if someone was writing a Mercurial plugin or patching Mercurial they would care.
Python 3.4 comes with asyncio, which takes a lot of the ideas of Twisted but forward-ports them to the standard library with cleaner language support. So for new projects, Twisted shouldn't hold you back - just use the standard lib. For legacy Twisted projects that are thinking of porting it's still an issue.
Twisted contains a lot more than asyncio does. asyncio is the equivalent of Twisted's Reactors, which are the internal bits which manage the basics of the async event loop, watching file handles, etc; but Twisted contains a great many abstractions on top of that, not to mention the many protocol libraries.
Luckily, a Twisted Reactor can be built on top of asyncio, and this will likely happen as people port more parts of Twisted to Python 3 (it's a long-running project with fairly little interest from developers willing to put work into it).
Alternatively, people could start to build new libraries that implement all the abstractions and protocol implementations that Twisted has to offer. I think it'd be preferred that even if each abstraction/protocol were a separate repo and installable package, they'd all be under the same "banner", so that everything interoperates correctly and using the same set of abstractions.
Standard library doesn't always make things easier. We have urllib but do we recommend requests for doing http requests? So either Twisted is ported or someone else write a new Twisted-like (but simpler?). I know Guido doesn't like callback-style programming.
The point is some developers don't want to reinvent Twisted on their own. They like Python 3 and they want to keep up with Python 3 but they don't want to move away from Twisted. Just like I am asking you to write your own Django because half of the things to build Django is in standard library.
> I'm not sure I understand why any python developer would care
And you did say that some people - people who write plugins or develop Mercurial for living - do care later in your sentence. That's some developers. And the parent was asking whether Python 3 was safe to use. It's nice to know that some major Python projects are not ready for Python 3.
This has very little to do with Python developers deciding between version 2.7 and 3.x. If you wrote a library or an app in Python 3.x packagers should require the appropriate version of Python as a dependency. Sam with v2. Developers shouldn't worry about that.
> Who the hell thinks it's OK to store non-encrypted passwords in this day and age?
The post gave no indication how Cricketer was storing the passwords. They may very well be stored encrypted.
You can send plain text passwords back if you've encrypted them, you just have to decrypt them first. There's no point at all in returning the results of encrypting a password if the clients don't know how to decrypt those results. Given that the API uses plain text HTTP, I doubt that the passwords are encrypted.
What the passwords are not stored as however, are hashes. A hash is not the same as text that was encrypted. A hash is a difficult to reverse unique identifier for bit of text.
Having said all this, it is funny to see your post, and all its replies making fun of security incompetency while also being incompetent in themselves.
That's not true at all. If you use secure encryption to store plain text, and proper use of HTTPs to transfer said text, that's secure. It's not as bad as obfuscated text. What you've said is just plain untrue.
One problem with storing passwords is that there is no good reason to. The other security issue is that people reuse passwords. So everyone should be creating hashes instead of encrypting passwords, but encrypting text, and transmitting it securely is still secure. This API didn't do that, it did a lot of things wrong, but these comments are all pretty ignorant as well.
It's just one inane comment after another in this thread.
It is secure against man in the middle attacks, but still if the password database is leaked, then the pain text passwords are most likely also leaked and you have to tell your users to change their password everywhere where they have used the same or a similar password.
You're running Ghostery for the purpose of blocking W3Counter and every other site like it. You can't really do that then lament the fact that it worked. I'm not going to invest time and effort into evading you; if you want to see web stats sites, you can just turn off the extension. Somehow I don't think there are any Ghostery users looking to sign up.
I meant you should use a different domain for static content on your marketing page, and I'm not lamenting anything. Just giving you some advice. Ghostery has been installed over 1 million times just in Chrome. Any one has ghostery installed and is going to your site will see a completely broken webpage.
Why was leobelle being downvoted? I can understand disagreeing with what they were saying. It's an opinion after all. But, what they were saying wasn't that far off base..
Maybe if Ghostery was developed in a half way decent manner it wouldn't have a bad history of breaking sites and would block tracking more intelligently rather than blanket blocks of domains.
I have noticed though that experience become a liability. If you wrote JavaScript for IE 6, a lot of the optimizations and things one did to make sure things worked in IE 6 are no longer necessary. One should be ready to let go of things as soon as they aren't necessary anymore. Always keep learning and know why you do the things you do with code.