If anyone has gotten Windows 2000 to connect to the internet, would love to take a stab at it.
294 karma · joined April 5, 2016
If anyone has gotten Windows 2000 to connect to the internet, would love to take a stab at it.
- Unsure about whether the cost and time spent were actually worthwhile, or whether self-learning might have been a better option - Bootcamps are not optimized for those who come in with basic programming skills
That second point was also exposed by a close friend of mine who decided to abandon her career in the aerospace/defense industry (she was an aerospace engineer) and do a bootcamp. She was top of our class in college, and she had done a fair amount of basic programming in tools like Matlab. She parlayed her bootcamp experience into a great job as well, but she often found that she was way ahead of the rest of the class. Luckily I've recruited from all of the bootcamps in my town, so I recommended a very good bootcamp with great instructors to her, and her instructors worked to put together a shadow curriculum of work to do while the rest of the class was still working through the main curriculum.
So, YMMV. If you can afford the cost of the bootcamp, it's a proven method to learn new skills and turn that into a new job, but the more programming experience you have, the more you'll find yourself far ahead of the rest of the class.
There's a lot about the article that smells bad.
So why should I be expected to regurgitate trivia at a whiteboard to get your job?
Edit: Not sure why the downvotes, would love to hear other perspectives about why I'm off-base. Thanks!
Javascript - either no Javascript, or very simple vanilla Javascript. No transpiling, no Typescript, no JSX, no ES2015.
CSS - Regular ol' CSS. Set a limit on number of lines of CSS you're willing to introduce per controller action and try and keep your project honest to that number. Avoid frameworks if possible, pick a simple framework for grid layout if you really need it.
As I've gotten to learn many different languages (PHP, Ruby, Go, Java, Python, etc) over the last 10 years, it has been really interesting to see how different languages and communities can vary so wildly in their quality of documentation.
As it relates to programming languages, Go's "Tour of Go" (https://tour.golang.org/welcome/1) is an excellent introduction to the language. I wish every language had an intro guide as good.
In terms of frameworks, I absolutely love the Ruby on Rails guides. They strike the right balance between staying high level enough for me to build a mental model of how the framework is working under the hood, while getting deep enough to be useful to solve individual problems I have.
Overall, I think the Ruby community has done a great job of documenting their libraries and frameworks. Whether it's Rails or Sinatra, or it's a library like Devise, Ruby OSS projects seem to tend towards thorough documentation.
On the flip side, Spring's documentation (and most Java library documentation) is absolutely atrocious. Spring in particular only seems to give you 2 flavors of documentation: a 10-minute tutorial, or a 1000-page deep dive in all of the corners of the framework. And Java libraries in general seem to have miserable, out-of-date, incomplete documentation.
1) The US has nothing to gain by taking down the internet infrastructure via malicious means.
or
2) The US has better access to these systems to take them out directly rather than forcing them down via DDOS attacks.
But he's not exactly the right person to garner sympathy when he's made hundreds of thousands of dollars and has nothing but a fruitful career ahead of him despite his criminal record.
And make no mistake, sympathy is what he wants for publicly posting this ridiculous article.
Also, stop acting like you're smarter than everyone else. Humility is a virtue in this industry. Those skills you have today might be completely useless in 5-10 years, you always have to be innovating yourself if you want to have a long successful career in tech.
I think not. I might not like Hillary, but it's an absolute joke that Adams thinks that Trump is the embodiment of some pure form of democracy. He's changed the game in American presidential politics (he's basically gotten rid of the idea of a "gaffe" at this point), but his goal is selfish; he wants to be president for his own benefit, and he'll say anything to get it.
I've started to understand why large companies that attract high-quality talent (i.e. Google) put new developers on QA... you need a developer's mindset, while not being involved in the day-to-day software development to do effective and creative manual testing.
Hobby projects? Less so, particularly if it's just me writing software. However, if I'm writing a particularly hairy piece of logic I'll absolutely write some tests for it (for example, I wrote a JS calendar plugin just to see if I could do better than the many existing ones, and I did all of the date logic myself using JS's terrible Date library).
I'm not sure I follow here. You want 75% of the salary to do the same amount of work? That doesn't really make sense to me. You also have to take into account that companies have to manage the overhead of having more employees (more mouths to feed at events, more HR costs, at certain thresholds it triggers new legal requirements for the business). I doubt you're going to find a lot of takers from either employees or employers.
It sounds like you're dealing with a personal issue, which is that you feel like your company is "try[ing] to squeeze all the possible juice" from you. This sounds like you're burned out on your job. Maybe it's time to find a new company, a new position, a new work environment, something that will make you happier than you are now. I'm not sure that less hours and less pay is necessarily the problem here.
I'm not sure about why Brazil and Crimea are not allowed to participate, but I know Cuba, Iran, Syria, North Korea, and Sudan will all be prevented due to US sanctions against those countries.
For us, it's about keeping the barriers to communication as low as possible. We do pair programming, so we're already very much oriented to frequent communication. While tools like Slack and email get the job done if your team is working remotely, nothing beats being able to turn around in your chair and quickly engage another pair of developers (or the entire dev team if necessary) in a quick discussion about something. This extends to the rest of the team (designers, product managers, relevant business analysts, etc). At any point I can walk 30 steps or less and talk to anyone from the product or business teams about requirements.
Admittedly we keep strict working hours to maximize the amount of time the team is together (8am to 5pm, everyone takes the same lunch hour). The flip side of those strict hours is that we are never asked to work overtime or weekends. We come in, the entire team works for 8 hours together, and then we go home. People never believe me until they see it in person, but our office will be buzzing with work at 4:58, and then be a ghost town at 5:02... unless we decide to play some post-work ping pong or grab a beer!
I'm not saying that I don't think that remote work can be effective, because I've seen it work. But I think it's disingenuous to say that remote work is equivalent to colocation. The best argument I've seen for seeking remote workers is when a company is located in an undesirable city and struggles to attract talent (i.e. a company in Paducah, Kentucky will struggle to attract candidates in a way that a company in Denver, Colorado probably will not).
I don't foresee the end of Jira any time soon, but I do think that they will go the way of other enterprise bloatware eventually.
For languages I'm comfortable in, IDEs all the way. I'm particular to the JetBrains suite (RubyMine, IntelliJ, PyCharm, etc). I like the consistency across the different products, and for multi-language projects (i.e. my current project involves Rails apps, Java/Spring microservices, and lots of ReactJS) IntelliJ Ultimate is unbelievably awesome for my productivity.
"When you live in a capitalistic society, the currency of the dissemination of information goes through capitalistic channels. Would Noam Chomsky object to his works being sold at Barnes & Noble? No, because that's where people buy their books. We're not interested in preaching to just the converted. It's great to play abandoned squats run by anarchists, but it's also great to be able to reach people with a revolutionary message, people from Granada Hills to Stuttgart."
The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either.
The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. It's a dirty solution to have to amend your commits to make changes.
Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.