587 karma · joined July 26, 2011
You should definitely take charge of 1-1s. Maybe try bringing a list of non-status related issues and hand them over. The problems you see, ideas you have, off-topic things. Make it clear to your boss that things aren't working.
1-1s are probably your most valuable tool. Often, you will discover problems and info you would have otherwise not known - "our lead developer seems depressed and was talking about quitting", "did you hear about that other project that started? It's in direct conflict with our plans...", "there's a conference coming up, we should present at it", and so forth.
An effective manager should, in my opinion, spend 50% or more of his time with his team. Working on the same topics, talking to them, helping to plan, fixing problems, finding resources, and doing 1-1s. It's no surprise that teams with the most problems often have a manager who is just not around enough.
For new managers, I always suggest the following resources as a great starting point:
- "Team Geek": http://shop.oreilly.com/product/0636920018025.do - "Managing Humans": http://www.amazon.com/Managing-Humans-Humorous-Software-Engi... - Manager Tools podcast: https://www.manager-tools.com
I should also point out that on the train, I have a table where I sit (not in my lap, that sucks). I also try to use a stand-up desk more for all-day laptop usage.
The problem for me was neck and shoulder strain. Constantly turning to the left or right always gave me problems. My posture degraded as I naturally moved farther back from the keyboard to take things in.
I dropped the second monitor a few years ago. My physical problems have gone away. I enjoy looking straight ahead now, and as others have mentioned, using a laptop on the train to code no longer feels limiting.
> ... He also consented to a search of his laptop and iPhone and gave officers the passwords to his e-mail and Skype accounts.
Poor guy. I think he should have talked to a lawyer first before doing all of that.
https://labnotes.org/ - fantastic, weekly summary on design, frontend, architecture, business, and some humor.
http://rubyweekly.com/ - a roundup of announcements, new gems, talks and more
http://www.evilmadscientist.com/tag/linkdump/ - monthly list of links related to science, hardware hacking, geekery
http://randsinrepose.com/ - a few posts a month, great advice and thinking about tech and team management.
http://consumeconsume.com/ - funny pictures of irony and shock, which always give me great material for tech presentations
For RSS->email I use IFTTT
I think the behaviour of the police was way over the top, but the way the kids acted was not smart, and I wouldn't be surprised if the police actions turn out to be legal. You can't just refuse, it's never going to end well. The only option is to comply. If the police are out of bounds, the challenge has to come later, in court, not on the road.
This holds true for small projects, but as soon as you are working within a large, complex system that involves multiple teams, the benefits of using standards pays off.
I struggled in the past working on projects with companies that had built dozens of loosely-defined APIs, built with the good design intentions in mind, but suffered later from incomplete or inconsistent implementations. The app codebase became much fatter, in an attempt to abstract away those differences into a consistent mental model.
When complexity and communication reaches a certain threshold, it makes sense to invest in standardizing the APIs and responses. I've seen the payoff and am convinced: client libraries and frontend implementations get much simpler, documentation becomes easier, and discussions about how to make changes or design new APIs all but go away.
On the other hand, for small teams and simple services, using a standard like this is probably overkill, unless everyone involved is used to doing APIs this way.
On the other hand, we've also hired people that have not much happening with their public github profile. We still ask to see code they might have worked on (job-related). If they can't show that, we try to have them pair with us on something simple. We have hired people in this situation, but I'm sure we've missed others that may have worked out.
If a young Carmack came through our interview process, I'm pretty sure our team would recognize his talents when asking him to go through someone else's code.
For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typical, comfortable development environment. We've seen candidates struggle with the latest Ubuntu, installed that morning to impress us. So we don't want that.
During the hands-on interviews, we ask to see a side project, or any code they are mostly responsible for, and familiar with. We ask them to explain code, maybe change something, refactor a test, etc.
What we don't tell candidates is that this part of the interview is also about how they use their tools. It's important to see how good they are with their editor, command-line tools, can they type well, do they get easily distracted, and so on.
One of the most effective interviews we do is for project planning. A problem is explained in detail and the candidate is asked to design a solution. Not in code, but to talk it through in detail, drawing or writing docs/stories if needed. This phase helps show us how they break down a project, ask questions, negotiate features, and look for opportunities to reduce complexity. Bonus points for making a pen-and-paper wireframe or throwaway prototype.
What we refuse to do is the "puzzle" problems, whiteboard code (which makes no sense), or tricky technical questions. We instead want to find people that use best practices, don't re-invent the wheel, tackle problems pragmatically, and are good with their tools.
Over time, this approach seems to work well. However, we also discovered that we have to re-train and test our own interviewers. Without that step, the process can change unexpectedly, become inconsistent, or unfair. Don't just assume your staff is interviewing well - take time to check it out and help them get better.
That being said, I'd like to try this service, the guys behind it seem to really know what they are doing.
We're looking for bright hackers in the EU that have good skills and a strong understanding of product development.
The official phonebook of Switzerland, and one of the most popular platforms for connecting businesses and users. Releasing new features quickly to market: restaurant bookings, turnkey website creation, social integrations, weather, maps, and more.
We have a strong team of agile developers that use Rails, Javascript, node.js, RESTful APIs, and data-driven decisions to pull it all together.
Job Posting: http://local-ch.github.io/frontend-web-developer.html
About our engineering and culture: http://local-ch.github.io/
But nothing quite as frightening as finding three rats one evening zipping around in my kitchen, ripping apart ketchup packets. Or the time my downstairs neighbors had an angry rat trapped in their kitchen (which was disposed of with a hockey stick).
I called the NYC Health Department hotline maybe 5-6 times. At that time, calling the number led to a voice mail menu, and the first options was "if you would like to report a rat infestation, press 1". This is no joke, some buildings were really and truly infested.
The city did nothing but to place poison rat traps on the streets. Only once did someone respond and come to our building, he just suggested that we fill up all known holes in our building with steel wool. The local hardware store had bulk packages of the stuff for sale, a popular item.
Our Chinese landlord solved the problem by calling a neighborhood expert. He brought his gigantic cat, who lived downstairs in the basement for several weeks. After that, we had no more rat problems for a long time.