|
There are three categories of questions that all technical job applications should be prepared to answer. Context has been given where necessary, and for the technical questions, links leads to helpful resources or answers. Extra-special secret answer: your parachute is plaid
|
|
|
|
|
Before courts, laws, and complex social systems, we had promises—the assurance that something will be done. Promises are still one of the most important tools we have to help us navigate social encounters. "Mr. Scott. Have you always multiplied your repair estimates by a factor of four?"
|
|
|
|
|
Google is planning to “spy” on its employees for the next 100 years in order to find the secret recipe of keeping them happy and more engaged for a longer period of time, Google’s Senior Vice President of People Operations Laszlo Bock revealed in Harvard Business Review. I'd say step 1 should be: Stop tracking them
|
|
|
|
|
Does it reveal how it intends to keep them alive that long?
|
|
|
|
|
Well, they are employing "Mr. Singularity[^]". Maybe he's got something up his sleeve?
TTFN - Kent
|
|
|
|
|
And then in 2006, we delivered our first 100 percent agile project. It wasn’t all peaches and cream. We struggled to let go of things RUP had taughted us over the years. But nothing resists positive reinforcement, and soon after we would have reinvented the way we build software to fully embrace the agile manifesto. Seems good advice with everything
|
|
|
|
|
Collaboration among developers helps them stay innovative while also advancing the company's business objectives. So link arms, and agree on the best brace style
|
|
|
|
|
Kent Sharkey wrote: Collaboration among developers helps them stay innovative while also advancing the company's business objectives.
Interesting. I first took that to mean developers inside an organization, to which I would say, what total BS. But the article is talking about developers collaborating with other companies, and to that I would have to agree with the article's main points.
But others may disagree with even my "interal collaboration is BS" opinion - I tend to fly solo and in my own airspace, and I enter a "collaborative space" only when someone clearly demonstrates their ability to think, which is rare. Or, more precisely, someone that I feel is on par with my skills or has greater skills, and I'm not talking about just technical skills, but also completely different domain knowledge. Even then, I find people get stuck in their own paradigms of thought. And that's fine, if you can convince me that a different way of thinking is better than what I've figured out in my +30 years in this absurd industry.
Marc
|
|
|
|
|
Marc Clifton wrote: Or, more precisely, someone that I feel is on par with my skills or has greater skills, and I'm not talking about just technical skills, but also completely different domain knowledge.
If you want the other to have greater skills than you to collaborate, you should also take the other position about half of the time. You may provide insights to others by now instead of the other way around.
Wout
|
|
|
|
|
wout de zeeuw wrote: If you want the other to have greater skills than you to collaborate, you should also take the other position about half of the time.
I agree -- the difference for me is "collaboration" vs. "mentoring". I quite enjoy mentoring and do so quite frequently, but creating a commercial product can be put at risk when collaboration is mistaken for mentoring. I'm a good example of that -- about a year and a half ago my client started mentoring me in Ruby on Rails. There were a lot of mistakes I ended up making in the production code base, none of which were an issue (source control to the rescue!) but it took about a year of mentoring before I was able to fill the role of a collaborator. Even now, with the business domain itself, it's still 50/50. The technology was relatively easy to learn, but the business domain has years and years of knowledge that is captured only in a few people's heads.
Marc
|
|
|
|
|
I generally agree about collaborative/open work spaces. The only times I've felt them to be a net benefit has been when the primary bottleneck in my productivity has been the transfer of domain knowledge. Even then the environment, especially when multiple conversations start running at once, drives my stress levels up greatly leaving me much more exhausted at the end of the day. It's still tolerable for occasional practice, but I strongly suspect that trying to work in that sort of environment on a daily basis would burn me out out to kill the nominal knowledge xfer benefit.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Kent Sharkey wrote: So link arms, and agree on the best brace style
Or agree that the brace style doesn't matter as long as the style is consistent within the same source file.
There is no tangible benefit to using any particular brace style. This has been studied.
The book "Coding Standards" states with regard to bracket style - "I don't care". The authors are long-time C and C++ experts. Two of them are on the C++ standards committee.
A paper I have somewhere about C coding rules was a study of a number of projects over years, and found that out of 400 coding rules, only 10 of them had any effect on reducing the number of bugs. The rest were consistency for consistencies sake. There should be a tangible benefit to justify a rule. Often, such rules are just made because people like what they do. That's not a good justification for a coding standard.
|
|
|
|
|
All true, but it's the trivialities (like brace style) are what wars have been fought over for decades.
TTFN - Kent
|
|
|
|
|
I see it more as a social thing. When you're working with a team, you will have to converge to a limited set of visions, of which coding standards is a very superficial one. If a team member can't deal with a coding standard, then he sure won't be able to deal with deeper differences of opinion. Also I do prefer a code base to have a coherent feel, of which the coding standard is the first most visible no the surface.
Wout
|
|
|
|
|
Lenovo is recalling certain ThinkPad battery packs that could be a fire hazard due to overheating, which could ultimately also lead to computer damage. "I am the God of Hell fire and I bring you fire, I'll take you to burn"
|
|
|
|
|
Both Microsoft and Google have long worked on getting users answers without having to click through a number of websites. At Google, the current result of this is the Knowledge Graph and at Bing, it’s the company’s entity engine (previously referred to internally as Satori). "It's these expressions I never give that keep me searching for a heart of gold"
|
|
|
|
|
Quote: I understand why people might look at new practices with skepticism. The enthusiastic adoption of a new practice by one group creates tension with others who do not adopt the practice. The adopters can make the non-adopters feel slighted and invalidated; as if everything they had ever done in the past was wrong. The adopters, in their enthusiasm, may claim that adoption is a new requirement of professionalism. The non-adopters may claim that the adopters are fanatics who are detached from reality and ignorant of the past.
The Corruption of Agile[^]
|
|
|
|
|
Duncan Edwards Jones wrote:
The non-adopters may claim that the adopters are fanatics
who are detached from reality and ignorant of the past.
Which is nearly always true. As we've learned from the past.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I actually know some people that work for holocracy.org Nice people.
But back to the point...I take a pragmatic position. Show me you can actually deliver something in a better way, otherwise shut up.
Sort of bursts the bubble of all those theoretical discussions.
Marc
|
|
|
|
|
Quote: (Submitted on 26 Mar 2014)
arxiv.org
In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves. This allows an attacker to mount a malleability attack in which it intercepts, modifies, and rebroadcasts a transaction, causing the transaction issuer to believe that the original transaction was not confirmed. In February 2014 MtGox, once the largest Bitcoin exchange, closed and filed for bankruptcy claiming that attackers used malleability attacks to drain its accounts. In this work we use traces of the Bitcoin network for over a year preceding the filing to show that, while the problem is real, there was no widespread use of malleability attacks before the closure of MtGox.
Quote:
Bitcoin Transaction Malleability and MtGox (.pdf)
6 Conclusion
The transaction malleability problem is real and should be considered when implementing
Bitcoin clients. However, while MtGox claimed to have lost 850,000
bitcoins due to malleability attacks, we merely observed a total of 302,000 bitcoins
ever being involved in malleability attacks. Of these, only 1,811 bitcoins
were in attacks before MtGox stopped users from withdrawing bitcoins. Even
more, 78.64% of these attacks were ineffective. As such, barely 386 bitcoins
could have been stolen using malleability attacks from MtGox or from other
businesses. Even if all of these attacks were targeted against MtGox, MtGox
needs to explain the whereabouts of 849,600 bitcoins.
With friendly greetings, 
Eric Goedhart
|
|
|
|
|
We need a raised eyebrows emoticon.
Interesting.
cheers
Chris Maunder
|
|
|
|
|
|
The truth is, I don’t have time to actively scour GitHub for issues/libraries to contribute to. But when I’m using a library in my own project, and I wish it had feature X or that bug Y was resolved, it’s a no-brainer to solve it and contribute back! "What goes around, comes around"
|
|
|
|
|
We are releasing the full source code of JustMock Lite, complete with unit tests, examples and build scripts. Actually, you can skip the rest of the post and jump to GitHub to check the goodies in the package. It uses Apache 2.0 license, so you can start using it right away. Everyone keeps making fun of .NET
|
|
|
|
|
I've been using JustMock for a while now. It's pretty damn awesome.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
