adeaver
Disney cancels 'Star Wars: Attack Squadrons' game
Fake Geek Guys: A Message to Men About Sexual Harassment
Hint: Phone functions
And I've also found HighCharts extremely limiting. I ended up having to break things in HighCharts to meet some requirements. Granted that's a project problem not a HC problem, but D3 made much more sense for me.
To each their own :)
Microsoft Unveils New Anti-Google Gear
As it's not so much the occasional 'Crap, we need X stat!' that is a problem, it's the constant assumption that your boss can call on you any time and _expect_ you will comply.
That's just a shitty boss. Regardless of their title.
If I change it at that point then I'm either being disingenuous or taking away the aspect he wanted to talk about.
All that said, if I put my github url on the resume then it's fair game to _talk about_. My point is (same as the articles) using it as a filter is generally a bad idea.
I realize this is anecdotal, but 95% of the public code in my git repo is stuff I did as fun. I didn't care about being right, or care about memory issues or being thread safe or anything other than 'I wonder if...'
In that instance, and I suspect a lot of other people public where they aren't contributing to something using the repo code as a talking point is counter-productive.
Why did I do it that way? Because I wanted to see what would happen.
The presumption that he's trying to destroy the original developers livelihood is naive at best.
However if you insist on focusing one a singular viewpoint then I will remove myself from the conversation.
Of if you live in a majority of the US, when you change the clocks, change the batteries.
Neither of these schedules will sneak up on you. If you don't change them and it wakes you, it's your own fault.
Sorry to sound snarky, but it's not _that_ complicated.
1. "I hear you about X but we are doing Y anyway."
2. "I hear you about X and understand you viewpoint, however we need to go with Y because..."
I'm okay with #2. #1 will drive me away. And it should. It's disrespectful and basically tells the other person that you have no regard for their opinion and that you only ask to satisfy a rule or expectation. If you are aren't going to have a discussion about why Y is the solution and were going to do it regardless of what anyone else said, then why bother even asking?
Do you have so much work that it can't be done with your current staff in 40 hours/week? Hire more.
Is your management so inept that your employees are forced to work more to keep up? Training will help.
Many people will willingly work extra when they need to (trying to squash that one last bug or trying to squeeze in that new feature) but rail when it's expected and demanded for no legitimate reason.
Calling something Semantic UI and comparing it to another library, that more follows the actually meaning of semantic, is silly. Yes you can change the class name but setting up the name as something meaningful, something semantic, such as 'submitButton' lets you redefine it in the CSS.
If I'm building something that multiple clients will use I don't want each client having buttons with class names specific to the client, but something I can modify easily in the CSS to get the look and feel they want.
It's ass backwards.
That said, he (and anyone doing it) should probably check in with the doc just to make sure something internal isn't getting out of whack.
Someone suggested this and all I can say is that after a few years I don't have the allergy attacks anymore. Not even when I mow the lawn.
Since I stopped taking Claritin or anything like it I can only assume the honey did _something_.
No, all it shows is that they wrote some code and put it on a website.
The developer that has just a resume might be just as (or more) skilled that the one that uses github but for whatever reason can't post code up like that. To exclude someone simply because they don't have an active github is foolish.
However did you screen, interview, and hire people before github came along?
Fairly anti-climatic. For someone that it comes easy too there is no real emotion or sense of accomplishment.
It would be like trying to explain the color green to someone that was born blind.
So it's not editorializing, or if it is, the NYTimes is the one doing it.
Add to that the fact that most tech interviews are held in non-real world situations and it's easy to see why some people have problems. Putting a person in a room with a piece of paper with a chunk of code that has a 'hidden' flaw with no access to any other resources isn't real-world.
All of us have access to books, manuals, the code, google, any number of places we can use to help.
And usually these interviews focus on nuances of a language or a programming trick that you only know if you've seen it before or encounter it regularly.
The codebase I'm working on now targets the iPad. If I were to interview with a company and the tech reviewer asked me about an IE specific hack chances are it would take me a while to come up with it. Assuming I've encountered it before.
BioWare writer quits after death threats to family
Make connections however you can. That way if something does happen you can reach out to them to see if they know someone or might know someone who knows someone that can help.
Worked for me (and many others) in the past.