Ask HN: Best practices for onboarding new employees? - <AUTHOR> I'm starting a new gig as a product manager with a startup in a few days. ~20 employees (most but not all in one building). Good customer traction.
I'm building a personal checklist of onboarding items. It contains the usual categories - hr/payroll stuff, phone/email/slack setups, product details, customer commits/requests, risks/issues, etc.
The main concern is how to be productive from day 1 without being a time suck for the CEO & CTO.
Does anybody have 1) a shareable best-practice checklist, or 2) a methodology of quizzing my new coworkers?
Appreciate it. <comment><USER3> This is how I've seen it done in very small companies:

1\. Greet the new person and ask them what they are doing there? Are they a vendor? client? someone who accidentally walked in? Oh, they're a new employee.

2\. Ask them if they know what their job is supposed to be. If not, find them a spot to sit down while you ask around.

3\. Ask IT to get them a laptop. If they don't have one, send out to get one from best buy. When they ask what type say "good, but not too expensive"

4\. Ask them how their day is, if they want coffee

5\. Get back to work, forget about them.

6\. Go back and realize that no one knows what they are supposed to do.

7\. Randomly assign them various tasks.

Whatever best practices are must surely be the opposite of this.

At large companies I have seen:

1\. 12 binders full of details about healthcare, policies, what happens if you pass away and other remote events

2\. Orientation that feels like an abstract business school course

3\. On day 1, you are asked to do something really simple to get your bearings.

4\. Day 2, you are asked to do something really massive because by now you must surely know your way around.

<comment><USER4> Just don't spend 2 weeks on step 5, because that happened to me at my current job. They completely forgot they even hired me and wondered who that guy was in that cubicle over there.

<comment><USER5> I cant tell whether you are joking. Seriously. What did you do for 2 weeks?

<comment><USER6> He's on HN on day 3, just hoping it turns into 2 weeks

<comment><USER7> I would say this, and I can't find a time period after which it becomes OK. And that's fine. Seems you have some covert contracts. I've been the black sheep at several SF jobs, not in on the FB and Slack OFftopic channel fun. Invited, but not partaking, and eventually being ousted by same people if I don't leave first. The importance of a right fit and fail fast mentality. But it's a 2 way street. Observe the specimen for a statistically meaningful time period, or chill and trust the hiring process.

</comment></comment></comment></comment></comment><comment><USER8> When I start at a new company I create the "Onboading Guide" I wish I would have had. I take notes on all the things I had to do and where (and sometimes how) to do them. I include a "Link Bank" of all the random URLs that no one knows because they all have them in their history or bookmarks, and all the IT requests / installs that need to happen. As I continue with the company I update this doc as things change or new things come up and refer back to it myself when I need to remember how to do a rare but important task. This is the third company I've done this at and each time I get a bit better at creating it, and the feedback I get from new team members I send it to is really positive. Crucial - This doc is online in a format that others can contribute to and I encourage new team members (and interested current team members) to update it themselves.

<comment><USER9> Haha, I just did this for my current employer. It is really appreciated, too. Sometimes long-time employees even realize things they need to do that they should've done during on-boarding.

</comment></comment><comment><USER10> What follows is my usual way of working and/or the type of behavior I appreciate when onboarding someone in my team. YMMV.

1) You're going to have plenty of questions, and a lot of the stuff you'll see / hear / read won't make sense at first.

\- Accept this fact

\- When you get stuck on something or don't understand it, make a note of it and move on to another topic. You'll have plenty to look at anyway.

\- Keep a running list of questions and ask for some dedicated time slots with your managed / mentor / peers to go over the list. 30 min a day or so should be enough to go over all your questions without being a time leech.

\- Armed with your answer, go back to the documents that didn't make sense. Read them again. Is it all clear now? If not, write down new questions.

\- When you're really stuck and can't make any forward progress without an answer, raise your hand (metaphorically or literally) and ask for help. DON'T wait for the next dedicated slot - I'd rather "waste" 15 minutes dealing with an employee issue than have them waste an entire day.

2) You'll see things that surprise you, or don't make sense, or could obviously (from your point of view) be improved.

\- Write these down as you notice them. You'll be amazed at how quickly you'll grow used to them and cease to notice them.

\- After you've settled in (a few weeks), raise them to you manager. "I was surprised by X", "how come everyone does Y", "at my previous job we used to do Z to manage X"... External feedback is always appreciated (or should be anyway) and this is your only opportunity to take stock of the issues with an external perspective.

3) Unsure what to do? Ask what needs to be done. What's the current hot topic, is there something urgent that nobody can get around to do or has the skills to handle?

\- There's ALWAYS something (or more likely a huge list of somethings) that needs to be done but somehow isn't making progress in a startup. It's not that they're unimportant tasks, merely that there's just too much to do.

\- This can score you quick points with the team, help you get a handle on the context, and fight the feeling of non-productivity.

<comment><AUTHOR> OP here. Agreed - #2 is great. I've bought a squeaky-clean notebook for the new gig. Page 1 is already titled "onboarding questions". /fistbump.

<comment><USER11> This is good but (and it's a big but) DO NOT ACT ON THEM IMMEDIATELY.

There are likely plenty of things that seem askew or just plan wrong - <USER2> many of them are - but you have neither the understanding or earned authority to act on them. I love the idea of inventorying things you think are issues, problems or mistakes then reviewing them after 3,6,12 months (you'll know when you have the right to question the status quo) and tackling the ones that you now KNOW are wrong.

A very common mistake of new members of a company or the workforce is to blow into an organization, shit on everything and destroy any chance of affecting change. Covey is right in "seek first to understand, then to be understood".

Now if you're a management consultant, do exactly the opposite of the above; that's why you get paid the big bucks - to rattle some cages!

<comment><USER12> I'd not say the opposite, just that same process, but much faster, and more blunt.

</comment></comment></comment></comment><comment><USER13> Assign a mentor and give the onboardee free reign over them. Make sure that the mentor is okay with it and make it clear to them that this can take as much out of their time as needed and it won't reflect badly on their perceived performance. If need be, allow them to be unavailable for X specific hours a day to allow for uninterrupted work on important tasks but otherwise remain totally there for the onboardee.

Accept that your employees won't be productive from day one, and they don't have to. If your employees can be productive from day one on tasks, you're probably postponing the real onboarding and making yourself feel good.

<comment><USER14> I have been on both the mentee and mentor side of this, and it's been my favorite approach. I would add a couple things.

1) Make sure the mentor likes this role, and that they understand it's their responsibility to guide the new person or to reach out for assistance if needed.

2) This person should be a peer, but that they should be able assign exercises to the new hire to advance their knowledge. Maybe this could be pairing on bug fixes.

Also, I don't know how well this would work at firms where nobody "has enough time" for this. How does one make the time, or change things so that people don't feel that way?

<comment><USER15> I recently found myself in this role as the mentor and I really appreciate the pragmatism of the approach. It wasn't deliberate, rather the new hire lacks professional experience and no one else knew what to do with them. So, I made myself available from day 1 and have been pairing with them extensively over the last few weeks. It's working out well. They are able to take their own tasks on now and don't require a lot of assistance. This thread gave me the idea that, now that I am at the end of this immediate on-boarding phase, I should take some notes and make them available for the rest of the team / department.

</comment></comment></comment><comment><USER11> You will probably need to push your boss(es) to be accountable but I like to define 3 broad goals over the first week: what you want to accomplish your first month, quarter and year (or 6 months). I further break this down into operational, strategic and personal. It will take you a little bit of time to define longer term strategic goals so this can evolve over your first month or two.

I recently started a new role (~ 2 months ago) and here's mine: First 30 days: * Learn product & team process so I can start to contribute to initiatives * Deep dive 3 areas * Review strategic roadmap for possible participation First Quarter: * improve understanding of function area/ application of product to customer needs * Master 1 core component of product * Map/Plan contribution to strategic initiative that matches org needs and my skills * Increase velocity/effectiveness of team contribution First 9-12 months: * Participate in a cross function/team initiative (like shared components, an integration project) * Take lead role on a part of the technical road map or strategic plan (execution)

Observations:

My plan still has some gaps & harder to measure things (vs true "goals") but is a good baseline and it will evolve,

I had to take the lead in pushing this with my managers, but they were receptive.

I'm experienced and confident enough to push for this approach; junior or new employees could easily do nothing beyond the typical corporate "justify your existence" career plans, which I think would be a real waste.

</comment><comment><USER16> What we are doing at my company (we have a general onboarding process):

Before the onboarding: \- we make sure all access has been give to every SaaS/software/etc needed for the employee to be able to work day one. We have defined a list of access needed for each job (engineering, finance, customer success, etc). \- we make sure that we have all necessary hardware (e.g macbook, screens, keyboard etc.) and that all necessary software/update are already there.

Onboarding day: \- First meeting is about presenting our company, what we do, our values, the market in which we work, etc. \- Second meeting is finalizing the computer setup (e.g. password) \- Third meeting is about security (my job). I'm presenting security, talking about our policies and etc. It's a pretty lightweight discussion. \- Fourth meeting is the HR meeting (e.g. sign the NDA, talk about insurance, etc.) \- Final meeting is a presentation of our application.

All along the day, we make it clear that they can ask any questions, anytime.

After the onboarding: 1 week after the onboarding day, we sent a survey about the onboarding day (what did you like, what could be improved, etc.). Only the Head of HR see this (for confidentiality).

</comment><comment><USER17> I usually prepare a laptop with all the necessary software, give all coworkers a heads up that the new guy/gal is starting next monday. On his/her first day I show them around, introduce the rest of the staff and cover the basic office stuff (where to find food, supplies, etc.). I encourage all staff to sit down with the new guy/gal to get to know each other.

You'll notice that at this point the new employee hasn't touched his/her new laptop yet. I think it's very important that the new one feels comfortable in the team before he/she can be productive. So I'm not convinced you should aim for maximum productivity from day 1.

When I look at the past when I started a new job there were two things that I hated:

1\. Not knowing who everybody was / feeling ignored 2\. Having to ask all the time for everything (PC, accounts, passwords, access to office, toilets, printer, etc.)

Good onboarding isn't hard. Just make sure that the new one feels welcome!

<comment><USER18> _Not knowing who everybody was / feeling ignored_

We give new starters a map of where everyone sits in the office as part of their first day paperwork (I drew my own on my first day.. it became standard practice after that I think). It's goes a long way to helping people know who's who, plus it means no one has to ask someone to repeat their name if they forget.

<comment><USER17> That's a great idea! Once I couldn't remember the name of a co-worker and after a couple of weeks it becomes _really_ awkward to have to ask...

</comment></comment></comment><comment><USER19> Check out the book "Work Rules!" by Laszlo Block. It describes the onboarding process at Google and specifically what impact certain behaviors had on retention.

It's a useful read and the practices they've adopted can be utilized in any size company as they're fairly straightforward. Things like: use a checklist, assign a mentor peer, etc.

</comment><comment><USER20> A piece of advice I was given once: "Listen with your eyes." Translated: when you're the new person in management meetings, pay attention to which person commands the most attention at a meeting. At one previous company when the owner/CEO spoke, very few of the C-level people would look at him, other didn't put down their phones. But when the CFO spoke, EVERYONE paid attention. It was a pretty solid leading indicator that this person had the most sway in the company. Later experience proved this out: he had the CEO's ear and anything he requested became official (solid CFO -- what he asked for was good for the company and the CEO knew it and appreciated it).

</comment><comment><USER21> Something I wish the companies did at my last jobs was tell me more about how the business operates. The first week or so at a job usually overwhelms employees with very low-level work (how the release pipeline works, coding best practices) , that it's easy to lose track of what the overall goal of the business is.

Taking the time to explain some of the higher level processes can provide a lot of context for why certain operations work the way they do.

I personally like to know:

1\. The history of the business

2\. Which problems it solves well, and which it needs improvement in.

3\. Which problems it has failed at solving in the past.

</comment><comment><USER22> Take all their time that you need and don't hold back. If due to all your questions they realize their onboarding process is weak then they'll at least know they have to put more thought into it. If you avoid asking questions then nothing might improve.

What's cool though is if YOU write the onboarding process from a new person's perspective as you go. Someone already working there trying to set up an onboarding process is maybe going to be blind to the things that new people might want to know.

I just started as a new dev for a medium-sized company and their onboarding process was literally a firehose of HR communications about corporate things and people's milestones and birthdays, a tree of links to various neglected documents in various disconnected systems ("Confluence for this, Google docs for that, oh and a treasure chest of MS Office documents and PDF's in Dropbox"), a neverending series of credentials-related mysteries, and here's a series of webinars we recorded 6 years ago for stuff we rarely use any more, watch all of them so you can be out of our hair. Oh and good luck if you need anything, your IT guy has better things to do than correct your stupid name in the directory.

Probably pretty typical but coming from small companies it's a total shitshow.

</comment><comment><USER23> Understand that different new hires have different strengths, weaknesses, and psychologies.

Some people on the Autism spectrum probably will have more trouble figuring out, on their own, the cultural norms of the new workplace. E.g.:

\- How okay is it to ask questions vs. figuring out things for one's self?

\- How often do coworkers want to communicate? (Particularly challenging for remote workers to figure out.)

\- In self-organizing teams, what's acceptable in terms of assertiveness in self-selecting what to work on.

</comment><comment><USER24> To answer the question raised in the title, biggest benefit is to assign an on-boarding buddy to the new employee. The second most recent new-hire in the same role is usually the best candidate.

For the question in the content of the post, figure out who to ask about each topic, don't just ask the one person who knows everything - that might not be the most efficient way to use their time.

</comment><comment><USER20> A deck of flashcards with the name and photo of some the most important people in the company, along with some of the most important people relate to the area of the company in which they will be working is very helpful. Certainly would have helped prevent me from exclaiming that the company org chart was "evidence on paper of confusion and lack of direction or vision" to the Chief Operating Officer on my first day. Fortunately she thought this was funny; once she walked away and someone pointed out who she was I added "and senior management is afraid to speak their mind" to the list of problems that company had. And no, I wasn't fired... worked there for several years.

</comment><comment><USER25> We're all human and changing environments can be tough. My first task as a manager is to always make them feel welcome and comfortable on their first day. Everyone can understand the feeling of being lost and unsure of what the next steps are.

I always detail the stupid things in an email before the new hire shows up. Where to park, what entrance to use, what to wear, etc. Always make it a point to greet them at the door on their first day. It can make a huge difference to see a smiling face first thing when you walk in as opposed to having to talk to a receptionist to page someone.

</comment><comment><USER26> One thing that I think would be useful is to decide IN ADVANCE a project you think the employee can accomplish in their first week as part of getting to know a codebase. I've been thrown into new projects where I'm expected to read thousands of lines of code and issue histories and then just pick subsequent issues and feature requests and implement. This kind of undirected noodling is awful. It can be very difficult even as a subject matter expert to immediately understand a codebase.

</comment><comment><USER27> Advice I'm usually hired to research, and implement: If you're looking for an onboarding workflow you will be able to find lots out there. The sales people will all say they can solve what you're after. Dont believe them until you can map your proceess out in detail for them in writing. Don't belive their technical sales person, talk directly to implementers as you will be handed off 3 times before the project starts and the message will be lost. If you can't it will be a mixed bag. I recommend looking at a modern hr tool like bamboohr, or adp workforcenow. For your size something like BambooHR is the best place to start to start and the price point is solid, and flexible enough for you to focus our as you go.

Key feature: A tool like Bamboo (I'm not affiliated) will create onboarding checklists and tasks for both the employee and internally to complete the setup tasks as needed. Multiple checklists (global, department and position) can be attached to each position and are ready for the next hire. This feature is missing from most hris, onboarding or applicant tracking systems.

I have sytemized and automated onboarding processes taking 21 days down to a few including external testing and checks. If you have some questions, happy to chat offline.

</comment><comment><USER28> We split our onboarding into a few parts. High level below. This is iterative so I suggest you setup an internal wiki and share so it can grow and adjust to your company and policies.

Day 0: which we refer to as the internal check list of things that need to get done. That includes: \- preparing all legal docs that have to be signed \- purchasing required equipment \- setting up accounts like github, google apps, etc \- setting up workstation \- installing software on PC

The goal of this process is to ensure that there is ensure the employee is ready to begin training right away.

Day 1: employee familiarizes themselves with work space, people, office, emergency contacts, tools, the wikis etc.

Day 2: business training - reviewing in detail all of our products and services, our customers, our business model, our vision, divisions etc

Beyond this training is role specific.

</comment><comment><USER29> At my current company, I am in charge of hiring and engineering management. We are a small startup that is doing some very interesting but technically difficult things.

After my own on boarding process and casually quizzing the rest of the team, I started to realize that everyone on the team, from their perspective, worked at almost a totally different company than everyone else. I don't think this is too uncommon, especially in the early days of a thing, but we had a team member leave us so I asked if I could do an exit interview. The candid perspective I got from him was invaluable.

He had a very similar experience to my own, where from day one expectations felt like shifting sands. I spent a few weeks really thinking about it and came up with this on boarding plan that we are using now.

I broke it out into 3 months. I then talked to our CEO and head of development about what they would like someone to know and be exposed to in our company. I then broke that out into two separate on boarding plans. One was focused on learning about our customer experience, and the other a technical track. Then I took a look at our stack and documentation, and started an overhaul to put easy to read and find docs in a single place and make sure that on their first day they could type one command and run everything they would ever touch.

On your first day at you start with us I provide the outline of what you can expect over the next three months, the customer experience track is actually pretty fun and by the end of month two you are working on an independent study with our data tools. The technical stuff is pretty light weight, but covers some of the stranger parts of our system. You're given plenty of time to learn and ask questions. The first month mostly working just with the developers and figuring out communication patterns and stuff. The second month you'd take on a small feature as a champion and work directly with design and product, and you're encouraged to explore through improving our docs/tests or building one off prototypes that you think would be neat with our product. By the third you've been exposed to everything in our universe and hopefully if we've done our job right, everyone feels like they have agency, know's who to talk to, and is really excited to work on some interesting and challenging stuff.

The dual on boarding curriculum are in a git repo broken out by subject and month and tied right to our knowledge base. I personally think creative agency is one of the most important things for getting the most out of new hires and setting the tone. So that was kind of the focus of the scaffolding I put together. You can squash a fantastic asset by being aloof, having confusing practices, or in general just not being sensitive to how people learn and being reactive to it.

</comment><comment><USER30> Find a way to listen to what's happening around you without being overly distracting. Bias towards current projects. Here's a couple things I've done in the past:

\- Sit on customer calls

\- Read whatever approximates the "done recently" engineering tasks: git commits, Jira, sprint boards, whatever.

\- Show up to meetings you weren't invited to.

\- Take 6 different people out for coffee and ask them all the same 6 questions. Whatever you want to know.

\- Sit on customer calls

\- Set up the product and try to do something with it.

\- Better yet, set up the product and try to do a thing a customer is trying to do.

\- Did I mention sit on customer calls?

Once you know what people are working on today, it's easier to pick up and help them. Then you can start in on your own initiatives with credibility and support from the people you've helped.

</comment><comment><USER31> Ask people to give you demos of what they're building. Schedule 30 minute 1:1s with as many people as possible, 1-2 a day. Write down what people tell you as much as possible; even if you don't go back and read it, the act of writing helps it stick.

</comment><comment><USER32> I would try to make them feel comfortable first. Everybody needs to adopt new environment, know about others' personalities. If you just want productive, you can just outsource to other companies.

</comment><comment><USER33> Don't forget to treat them all as human beings and not assets (and follow @picardtips on Twitter for other good management/random insights, it's totally been worth my time).

</comment><comment><USER34> A who's who list, org chart, and a wiki page of how to set your machine up to start working (as few steps as possible), plus a few wiki pages of house rules.

Maybe do something fun on the first day or week to make a lasting impression that they are valued. Taking a new employee out for lunch is a good one. I remember the company that did that and I was impressed (you usually have to wait until you quit!).

</comment><comment><USER35> Hire someone specifically for the role. Otherwise it will morph into an all- day time suck.

The good thing is you actually don't need someone with an engineering background for this. And that community building skill they acquire can translate into onboarding new users as well.

In short, its the perfect entry-level position for a candidate with a liberal arts background who wants to get into tech. Best of luck!

</comment><comment><USER36> This is one of those things where nobody can give you the list, you just have to make it for yourself. Personally I recommend sitting down with the new employee, get them setup, and record everything you do along the way. This will be a bit of work, but it really does make the onboarding experience great and requires only a little maintenance going forward.

</comment><comment><USER37> My 2 cents... Create a 1 pager in advance with:

1 - A few sentences on job description.

2 - Key metrics

3 - A list of contacts (including suppliers and customers) they should meet.

4 - A list of things to read.

5 - A list of meetings to tag along to.

6 - Someone who will take them to lunch the first few days.

This gets people who are moderately self sufficient a chance to be productive.

And if you can't supply a laptop on day 1, you're pissing money away.

</comment><comment><USER38> During one series of interviews I asked about their onboarding process. My question was the first time the person had ever heard the word, let alone what it meant. Their product was nice, and I am glad I don't work there.

You are ahead of the game against some at the very least by asking your question.

</comment><comment><USER39> As a software engineer in downtown SF, I invite the new teammate to lunch the first day. Help them relax after a stressful morning. Walk around the block for some fresh air and to see what food and retail is available. Have a nice lunch and chill. Refeshed and ready to plunge back in.

</comment><comment><USER40> I liked Sequoia's guide on onboarding : [https://www.sequoiacap.com/article/the-strategic-value-of- on...](https://www.sequoiacap.com/article/the-strategic-value-of-onboarding/)

</comment><comment><USER41> I believe trello or one of the other successful business SaaS (zapier or typeform) have a great onboarding board on trello. A quick google should surface it. Looked at it 6 months ago and thought pretty comprehensive.

</comment><comment><USER42> from your question, you just got into the company, hence, don't trust much from your direct employees before you do something to earn their respect. All of them truly believe to be more qualified to your position than you, a "newcomer straight out of street", and deserving of a promotion when you fails.

Find the person latest hired, most close to your position and pay him/her a lunch, take notes of the next steps ( which accesses are needed, to whom to speak, how is the politics, who are the known backstabbers, etc... ).

</comment><comment><USER43> Full disclosure I work on Greenhouse's onboarding product, Greenhouse Onboarding. [https://www.greenhouse.io/onboarding](https://www.greenhouse.io/onboarding)

A lot of people on this thread have illustrated the cracks that new hires can fall through when going through Onboarding. I don't have a list, but can share some general thoughts.

\- Make sure everyone is aware of their responsibilities for the new hire:(sounds like you're doing this with the checklist). At a small company most of the responsibilities will probably fall on the Manager. Make sure the manager knows what's expected of them, send them calendar reminders so they know they have to meet the new hire in the lobby at 9am on Tuesday (as example). Add a reminder that the Manager, or whoever, has to at least have the computer in the office on the first day. Ask the manager to set up 30/60/90 day progress check ins. You end up being a task master, but it will pay off when the new hire has a smooth and pleasant onboarding.

\- Engage with the New Hire before day one: At a minimum send them what to expect on their first day or their first week. A common thing I've seen at other companies, is that a lot of time and money is thrown into recruiting, and then the offer is made, and the candidate doesn't talk to anyone until their first day. Don't do that. The candidate has no idea what's going on, and it looks like you don't have your stuff together.

Instead use that time to keep them excited about their choice to join your company. What's your company culture like? What are some fun things they can look forward to once they join? What kind of problems will they be solving in their new role? List that stuff out and let the new hire know about it prior to day one.

You can also use the preboarding time to check off some of the mundane tasks that take up hours on the first day. Send them e-signature docs, benefits info, the damn alarm code instructions, prior to day one, so you don't have to sit there and watch them read documents for 4 hours. (obviously some paperwork will have to be done on site).

\- Make it about more than logistics: The other common thing I see happen is that companies think onboarding is about getting an i9 signed, and a computer set up. That's definitely a very important part of it, but onboarding should be focused on setting the new hire up for success. That means ingraining them in the company culture, and helping them understand what success in their new role looks like. Are you making sure they meet people in other departments or on other teams, so they can start to build a friend network in your company? Are you laying out 30/60/90 day goals for their role so they have a clear idea of what's expected of them? Is their manager scheduling regular 1x1s? Are you (the defacto people team) following up with them to make sure everything went well? Are you assigning a buddy to your new hire so they have someone to go to when they don't know where the extra paper towels are kept, or don't understand how to load the dishwasher? Basically, think of onboarding as building a support system for your new hire so they don't end up falling through the cracks and sitting in a cubicle for 2 weeks by themselves.

Hope this helps!

</comment><comment><USER44> You should look at www.rippling.com

</comment><comment><USER45> My company is about the same size as yours, although we hire a lot of interns each summer so we've probably onboarded ~40-50 people. Here are some things I'd suggest:

First off, I'd suggest that you change your stance on whether or not they should be productive on day 1 and whether or not they should be a time suck for the CEO. At a 20 person company, if the CEO isn't personally owning hiring, culture, and onboarding, then they're not doing their job. New employees are super expensive, and it's a no-brainer to invest an extra week or two of work to help set up long-term success. I'd suggest optimizing for how productive they are at ~3 months rather than on day one.

For us, the first ~week is pretty much full-time onboarding. That doesn't mean they're always doing stuff (no one can absorb that much information) but it means we have a pretty defined schedule for that first week. It's a mix of the following:

\- General company onboarding: this is mostly me and one of the other leaders at the company telling our story, explaining our industry, talking about how most startups work and then contrasting that against how we work. Going over the employee handbook with everyone, etc. We've found that any more than an hour per day of this type of thing turns new hires into zombies, but if you spread it out (normally 4-5 hours over the first week) they find it really valuable.

\- Job-specific training: For developers this means getting them into the code base (we normally do a lot of pair programming the first week or two until they're up to speed). For support it means learning the product, answering sample contact forms, etc. This takes up the majority of their time.

\- Getting to know the team: we schedule several activities to give new hires a chance to meet each other (if more than one person starts around the same time) and the rest of the team. Their peer mentor takes them out for coffee. They play board games or darts with various members of the team just to get a chance to chat. We have company-provided lunch once per week, send them on a scavenger hunt so they get to know the area around our office, etc.

\- Brain breaks: starting a new job can be really stressful, and most people are too nervous to admit that they're exhausted and aren't really retaining new information anymore. I'd suggest building in at least one 30-minute block each morning and each afternoon (maybe even more than that) for them to just go off on their own and read a book, mess around online, etc.

It took us a few years to refine this, and I'm sure your approach will be different. But I guess my main piece of advice is to just give up on the hope that this won't be disruptive. Whoever is primarily responsible for onboarding (ideally the CEO at first, or the new hire's direct manager once the process is worked out) should just cross off the first week on their calendar. Even if you don't know what you're doing, you can overcome almost all possible problems by just putting in face time and actually giving a shit about the person you just hired.

</comment><comment><USER46> Maybe this isn't quite what you are asking for, but after overhauling the onboarding process for my last few gigs, these are my broad takeaways:

1\. There should be a clear, linear progression of items for all newhires to "hit", along with expected timelines for each item. No "fanning" until they are out of the onboarding woods.

2\. Everything should be documented. The first item from #1 should be a landing page that outlines and links to every onboarding topic, list, or general reference point, in order, and grouped logically. This page should be the one and only place any newhire needs to go to figure out what they need to do, or what they need to know, about anything. Docs should also include team workflow, best-practices, and tips from previous newhires.

3\. Checklists are better than lists. Everybody has a tendency to get lost.

4\. To the extent possible, all access credentials and account registration should be centralized to a federated SSO account, and should be automatically handled with minimum input needed by the newhire. They should only have to set up their password and 2fa, and everything else should be automatically ready to go by the end of the first day. Again, this is the ideal, and the only place I actually experienced this was at Google. All HR B.S. should be done before the first day, or by lunch on the first day at the latest. Newhires should be able to hit the ground running.

5\. Other commenters mentioned the importance of newhires to keep detailed notes. Notes about what seems confusing, or strange, or important things learned, or ideas for improvements. Every. Day....Every. Thing. New employees are an EXTREMELY valuable resource, simply because they are the only ones with a fresh, external perspective of everything going on. They should be keeping detailed notes, and managers should be following up with them and their observations/questions at least once a week.

6\. Newhires should be assigned a "mentor" they can go to for questions about this or that, and that mentor should be one of the previous newhires that just got through the onboarding process. Not only will they be closer to each other in the "beginner" perspective, but this forces junior employees to get teaching/leadership experience very early on, forges stronger team bonds, reduces the likelihood of shy newhires from falling through the cracks, and helps distribute the handholding load normally bore by senior managers and employees that are probably overworked with more important stuff as it is. Even if all the mentor can do is link them to docs or point them to who better to ask, that is enough.

7\. Newhires should be responsible for improving and updating the onboarding documentation, for the reasons outlined in #5. This should be one of their first projects.

8\. Part of the documentation should also include a list of "go-to" people or teams for certain topics as well. Half the battle of getting one's bearings is knowing who to ask about this or that, and I've only ever seen this passed down from oral tradition.

9\. For the more technically inclined, one should have automation scripts to get their workstation setup the way they like as quickly as possible. Here are mine as an example: [https://github.com/thefunkjunky/gs- dotfiles/](https://github.com/thefunkjunky/gs-dotfiles/) . This would normally take me days to do manually.

10\. There should be a reasonable and steady progression of tasks/projects for newhires to complete to get them accustomed to the job, the technology, and the general team workflow. One tiny practice project followed by "ok now here's the job, good luck" is unacceptable.

11\. Not only should newhires be asking a lot of questions, but managers and other team members should be asking THEM questions as well. Make sure everybody on the team is getting familiar with each other and taking time to reach out. Most newhires will be shy, and it is up to everyone else to make the effort. Also, try to fit in a team social thing like beer fridays or something the week a newhire starts so they can get comfortable with the team outside of the context and pressure of work.

12\. "11" is a weird place to stop, but I'm supposed to be working, so here's a "12" to make this list a nice even number. I suppose that's enough to chew on for now.

</comment><comment><USER47> See here for templates that might help pull somethings together:

[https://www.smartsheet.com/free-onboarding-checklists-and- te...](https://www.smartsheet.com/free-onboarding-checklists-and-templates)

Assuming you have HR/IT set up and onboarding guides done and the general intro to company stuff set up etc: I have found the following to be helpful to getting team productive but your mileage may vary:

For engineers -intro projects with assigned mentor. short project (from few days to a week) on a specific small feature that is designed to take them through all tooling, codebase and environments that you use. Idea is to expose new hire to development environment in a controlled way, give them a chance to learn, document their frustrations/questions, discover who to ask, how to ask (e..g do you use slack, in person etc), how peer and code review are done etc and get them productive with a win that contributes to the product.

It takes time to set up - but its worth while and if you know your onboarding - its easy enough to review sprint plans and id suitable tasks ahead of time and after you do it a few times it becomes routine and expected.

For marketing team - similar usually get them to review a marketing plan in an area they are going to be working in and how that fits across marketing tools and evaluate it and present insights back to team at following weeks marketing meeting. Same idea - expose them, get their insights and get them talking with their team and have them work on something that is needed.

For sales team - take them through structures sales training: Product, customer value prop, competitive analysis, target customer profiles, critical problems we solve, scenario role play finishing with sales and product qualification (ie have a test they must pass so you know they have a minimum level of product and target customer knowledge)

For all new hires assign a mentor - person who will help them through their first week and first weeks tasks. At end of on boarding Ask new hires to rate their mentors and the onboarding process - you want your onboarding experience to be positive for everyone and you want it to get better.

You will be tempted to have recent hires mentors the next in- since many things will be fresh in their memory- this works but its also useful to remind established folks what entry is like and expose senior team to new team members and map mentors to incoming expertise (e.g. some senior engineers may know a specific area of codebase so will be a better mentor for that position etc) so don't do it exclusively.

with any new hire - do a end of day 1, mid week and end of week check in to make sure all is going ok and they have opportunity to ask questions/follow up (it is surprising how many HR questiosn come up on day 4).

This sounds like a lot - but its worth investing in it. Most onboarding sucks - it shouldnt.

</comment><comment><USER48> Here is my checklist.

1\. Compile a decent on-boarding checklist. This is best done during your own on-boarding as you go through the steps yourself. I usually just drop it in a text file and worry about formatting later. And even then most I would do is wiki/markdown.

2\. Pick a suitable initial task, which is trivial enough to not throw the subject in confusion mode, but still spanning through enough of the codebase/product, as it is supposed to verify how accurately the checklist from step one was compiled and executed.

3\. Be around to assist at any times and stress your availability - on- boarding someone is work and it won't do itself.</comment>


Turning Vim into an R IDE - <AUTHOR> https://medium.com/@kadek/turning-vim-into-an-r-ide-cd9602e8c217 <comment><USER2> I wonder about the point of torturing a minimalist text editor with no graphics support (such as Vim into a comprehensive development and visualization enviromment, by invoking several plugins and some very specific workflows. Would it not make more sense to take the interface (modal editing, etc) and wrap it into module that can be easily embedded into several different IDEs, to handle text-specific tasks? That way, there is a fully powered system that can handle all the other tasks that the text editor was never designed to handle!

<comment><USER3> Alternately, would it make sense in R to separate the code and the result instead of a WYSIWYG approach? This is how many work with tools like latex/pdf (among others), edit the source in vim and have a viewer window open next to it.

<comment><USER4> That's (sort of) how RMarkdown works.

</comment></comment></comment><comment><USER5> This article suggest a variety of plugins and then describes a fairly exotic workflow that's alien to my vim brain. I use vim because it's simple, powerful and available almost anywhere. By the time I've installed a bunch of non- standard plugins and learned a set of tool-specific commands, I'm no longer working with vim but some other IDE-type-thing that happens to run inside vim.

<comment><USER6> They basically talk about one single plugin: nvim-r, without linking to its web page.

</comment></comment><comment><USER7> This is a superb write up.

As an Emacs/ESS user, I was rather embarrassed/traumatized to see how well Ncm-R completion worked. I'd also somehow missed that there was a usable R LSP implementation around.

</comment><comment><USER8> As much as I love Vim and R, I think the experience is pointless without embedded graphs. It would be perfect if it was possible to view a graph in a Vim split.

<comment><USER6> If you want graphs, you're probably not working at the terminal anyway and you're most likely using gvim that integrates nicely with our desktop environment. You can display the R graphics next to the gvim window.

</comment></comment><comment><USER9> > Why Not RStudio?

> Yes, I know RStudio has Vim keybindings, but it isn't the real thing. At > this point, I'm ruined by Vim.

I say the next step is that we have NeoVim running inside of RStudio. I also think we will have that happening in VSCode a mind bending text editor inside of a text editor.

<comment><AUTHOR> [https://github.com/Chillee/VSCodeNeovim](https://github.com/Chillee/VSCodeNeovim)

<comment><USER9> I'm talking about the offical VSCode team's Vim extension.

[https://github.com/VSCodeVim/Vim#neovim- integration](https://github.com/VSCodeVim/Vim#neovim-integration)

"We now have neovim integration for Ex-commands. To enable,..."

</comment></comment></comment><comment><USER10> This setup makes for an interesting blog post, but it goes too far toward being an IDE for my taste. Part of what I like about Vim is that you can customize it to be anything from just text editing—albeit fast and productive text editing—to a full-blown (if hacked-together) IDE.

I think what I would like is a way to embed Vim or Neovim into Rstudio. Rstudio's Vim mode is nice, but I'm too used to my own customizations. It looks like people have experimented with doing this: [https://github.com/jalvesaq/Nvim-R/issues/142](https://github.com/jalvesaq/Nvim-R/issues/142).

<comment><USER9> > but it goes too far toward being an IDE for my taste

To be fair the Title is "Turning Vim into an R IDE :)

</comment></comment><comment><USER6> So the suggestion is to use the nvim-r plugin. This plugin uses a custom R lib you have to compile yourself. This may not be possible in every situation. While this is a nice solution for your personal work station, it sometimes isn't in a corporate context.

</comment><comment><USER11> The argument of "why not use R studio" was not at all convincing for me.

R studio already has vim key bindings, so trying to make vim into rstudio-like seems like spending time on the wrong problem. As in, even if you succeed beyond your wildest dreams you're still not going to compete with R studio.

Things that make Rstudio great that is not so easy to implement include the knitR integration and Rmarkdown integration and embedded graphs and most importantly Rstudio server.

</comment><comment><USER12> "ruined by vim" \- that's the word I was looking for:)

</comment><comment><USER13> Vim is a good editor but not the right tool for the job.

Embedded charts are not a use case for Vim. Some R charts are interactive too.

Vim mode is available on some R IDEs.</comment>


Are you patronizing a startup or a big IT company? - <AUTHOR>

It appears big IT companies have picked up a new trick from food and drink conglomerates. There are plenty of seeming quirky upstart food and drink brands out there that are in fact owned by large companies.
It appears there is a new trend with big IT companies launching what are essentially brands and masquerading them as startups.
Some of of these companies were indeed startups at some point.
Pivotal is one that comes to mind, they belong to EMC (if there ever was a non-startup)...LightCMS (Netsuit), Asana (Microsoft), Podio (Citrix).
Please post others that you know of. <comment><USER2> I thought Asana was started by one of the original Facebook guys? Was it bought by MS or did it begin as an internal MS product?

<comment><AUTHOR> Bought by Microsoft, but you wouldn't know they are affiliated with Microsoft by just looking at their site:)

<comment><USER3> I think you're thinking of Yammer, not Asana.

<comment><AUTHOR> You are right...for some reason I had thought it was Asana...maybe it is the rhyming of their names:)</comment></comment></comment></comment>


California approves solar-powered EV charging network and electric school buses - <AUTHOR> https://pv-magazine-usa.com/2019/08/19/california-approves-solarschool-buses/ <comment><USER2> > _The press release from the company said, "heavy-duty vehicles produce more > particulate matter than all of the state's power plants combined"._

> […] _for instance why only "10 school buses"?_

IARC has recognized diesel exhaust as carcinogenic (lung cancer) since 2012.

Are there other electric school bus programs in the US?

(edit)

[https://www.trucks.com/2019/03/22/can-electric-school- buses-...](https://www.trucks.com/2019/03/22/can-electric-school-buses-make- the-grade/)

> _Most school systems don't have sufficient capital to finance the high > initial costs of electric bus purchases and charging infrastructure > development, he said._

> _In the U.S., the school bus market is about 33,000 to 35,000 vehicles per > year – about six times more than transit buses._</comment>


Tech Shuttle Map of SF, With Restaurant Clusters - <AUTHOR> http://datawovn.com/#!San_Francisco_Private_Shuttles

<comment><USER2> Just eyeballing, I don't see that shuttle stops correlate more strongly with any of the items in the pulldowns than they do with simple population.

Indeed, since everyone shits the same, maybe the title of the post should be, "Clusters of Effluence in San Francisco".</comment>


Ask HN: Turning 40. 50+, what would you tell a 40+ you? - <AUTHOR> Want to know what 50+ would advise to 40  to stay relevant and beat autism and grow further.
You can suggest Books, ritual, habit, mindset, skills etc
My little background - I am turning 40 and working as engineering manager in Indian IT company. I also code in python and .NET. <comment><USER3> I could probably write a book on this subject!

In interest of keeping things short though I would just say this:

1) You are young, so young. You are much younger than you think you are. When you hit 56 like me you'll realize that.

2) Keep a positive, problem-solver mindset. In the words (roughly) of Henry Ford "If you think you can, you can. If you think you can't, you can't".

3) Go for a walk daily (30 to 60 minutes) and get 8 hours sleep a night - <USER2> negotiable.

4) Keep reading, keep learning.

5) Travel. Pick somewhere that will surprise you and try and live there for a while. I lived in Thailand in 2003 and it changed my life.

6) Worry less. You won't get out alive anyway.

7) Stay frugal (read Your Money or Your Life by Joe Dominguez and Vicki Robin).

8) Watch "The Sunscreen Song - 10 Year Tribute (Everybody's Free)" on YouTube! Great advice!

In many respects my 40s were the best years of my life. Good luck!

</comment><comment><USER4> You are young and your best years lie ahead of you! (I'm 55 and I know this is true!)

</comment><comment><USER5> My free advice is : Pack your parachute before you need it - at least two years income saved to call yourself "financially secure".

Contentment is important. Figure it out.

Learn at least weekly. Better daily. Not just monthly or yearly.

</comment><comment> a0-prw Do it now.</comment>


Keep Track of Your Productivity with CherryTomato - <AUTHOR> http://kristiandupont.com/blog/2010/06/keep-track-of-your-productivity-with-cherrytomato/

<comment><AUTHOR> ..as you can tell, it is quite experimental so I would love any feedback.

<comment><USER2> I will give it a try.</comment></comment>


First Startup of its kind - <AUTHOR> http://www.buynothing.io

<comment><USER2> Quite scary because I see people buying this for fun. There are a lot of startups struggling to find paying customers, with real products, and then you have this kind of joke that will sell more than those startups.

It's really sad.</comment>


Do you need to be a dick to be a successful leader? - <AUTHOR> https://www.youtube.com/watch?v=gRRvjZ_XNog <comment><AUTHOR> Saw the recent post titled "Be more unlikeable" ([https://news.ycombinator.com/item?id=23821121](https://news.ycombinator.com/item?id=23821121)) and thought to share this short documentary on the same topic.

It would appear you don't have to be a dick to be a successful leader. Sometimes you might come across as one. Also, that might be okay.</comment>


FBI says it won't recommend charges in Clinton case - <AUTHOR> http://abcnews.go.com/Politics/wireStory/fbi-recommend-charges-clinton-email-matter-40349756 <comment><USER2> Two Americas, indeed.

One for you and I, and one for the elite.

I held a clearance for 20 years, during which time I was in-briefed multiple times, received annual security refresher training, and de-briefed when I no longer required access to particular material. The regulations regarding the handling, processing, classification and storage of such material was made crystal clear on every occasion.

I have no doubt that had I done the same as Hillary Clinton, a "reasonable prosecutor" (to use the FBI's theoretical situation) would be easily found to go after me.

Some animals are more equal than others.

</comment><comment><USER3> No surprise here, the fix was in. Very odd conference though, he lists all manner of violations then says no prosecutor would take the case.

<comment><USER4> The people who are determined to believe the fix is in, will believe the fix is in.

Because what could be harder to believe than that Hillary Clinton is basically an honest person trying to do her job?

<comment><USER5> I am personally pro-Hillary, and she may be basically an honest person trying to do her job, but even I can see clearly that what she did was wrong. It was serious and shouldn't be hand-waved like it wasn't a big deal, even by supporters of her. Listing all these violations was essentially proof that she did something wrong.

<comment><USER6> If you believe that previous people in the same position also had private servers and received classified information on them, why do you hold it against her?

[http://www.cnn.com/2016/02/04/politics/hillary-clinton- email...](http://www.cnn.com/2016/02/04/politics/hillary-clinton-email- classified-colin-powell-condoleezza-rice/)

Do you not believe that things are "overly" classified, and are liberally and retroactively labelled as such?

<comment><USER2> _" If you believe that previous people in the same position also had private servers and received classified information on them, why do you hold it against her?"_

Two wrongs don't make a right. Should failure to prosecute prior crimes mean that charges for the same crimes in the future be dropped?

 _" Do you not believe that things are "overly" classified, and are liberally and retroactively labelled as such?"_

The regulations for declassification of classified material are quite clear about who is authorized to do it and when. Whether material is _overclassified_ or not is as irrelevant as arguing that the quality of the diamond in a stolen ring should determine whether or not theft charges are filed against a suspect.

Edit: I cannot reply to @projectramo in the thread, who asked _" Well, you can still go back and prosecute them now. Is that what you propose? That we also prosecute Rice and Powell?"_ My answer: yes, if the statute of limitations (if one exists in such a case) has not expired.

The law MUST be applied equally for all, or it is tyranny.

<comment><USER6> It seems it would be just as tyrannical to apply the law as it is written and not as it is intended.

Here is a law intended to keep vital secrets out of the hands of enemies who might do harm to the national interest. And you want to apply it, broadly, to government officials who are trying to do their job.

I don't think Rice or Powell intended to do any harm, or wanted to give any secrets out to any enemy. I also think the likelihood that their use of non- government servers on a tiny number of emails really caused such an issue.

Yet you are advocating to end their careers, put them behind bars, subject them to years of trouble.

Doesn't something seem off here?

(I am putting aside Hillary for now because she is just such an emotionally supercharged example at the moment that it is hard to talk about her and just discuss the facts, so I am using the other two as examples).

<comment><USER2> (I'm not sure why I can reply now but not earlier. Anyway...)

 _" It seems it would be just as tyrannical to apply the law as it is written and not as it is intended."_

I don't know if there is a difference here. The laws and regulations surrounding the handling, storage and transmission of classified information essentially boil down to: "Protect classified material from disclosure to unauthorized individuals, follow established procedures, and in the event you wish to stray from those keep in mind you're likely not authorized to make that final decision so consult with your security officer and ensure your bases are covered."

Let's assume that I, as a soldier or contractor, started using my private email server for work purposes that on occasion involved classified material. Maybe I didn't know what _exactly_ was classified (or how high), but that doing so was definitely something I was advised _against_ doing during my in- briefing and my annual security refresher training. Perhaps even _explicitly_ told that such a thing was not authorized.

I am, at this point, negligent in my duty to protect said material and I have violated an agreement I have signed with the United States government. If one or more unauthorized parties (whether contractors _I_ hired to set up the server or somebody else) accessed my server and saw that material, _I have broken the law_ even if I didn't pull a Manning or Snowden or intentionally give material to a foreign intelligence service.

You can bet that _my_ career would be in jeopardy and _I_ would be put behind bars and subjected to "years of trouble". Hell, I would likely be held in custody _during the investigation_ over concern of being a flight risk.

There's a reason why people who have had clearances are generally up in arms about this: mishandling and negligence is something they are repeatedly warned about and fearful of. To see the same rules and regulations that governed our activity (and in some cases really made our jobs difficult) so casually ignored and allowed to go without so much as a wrist-slap is infuriating.

It's not about a witch hunt. It's not a political thing. It's about seeing other people being treated differently in the eyes of the law. It's far from being the first time in America, but it's as disgusting and discouraging as any bit of fraud one hears about in the worst third-world countries, and for it to be given a free pass at such a high level (and be dismissed by so many for political reasons) I think indicates the poor state of health our democracy is in.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> As soon as Loretta Lynch announced that she would follow the recommendations of the FBI, I had a very strong feeling that there would be no charges filed.

</comment><comment><USER8> HN Discussion of actual FBI statement: [https://news.ycombinator.com/item?id=12037042](https://news.ycombinator.com/item?id=12037042)

<comment><USER9> That thread has been flagged, despite being clearly a reputable source and in scope for 'hacker news'.

There seems to be a cabal of down-voters to take politically undesirable stories off the HN homepage. For instance, a while ago there was a story called 'The Myth of the Lone Wolf Terrorist.' I read it, then when I clicked back to HN to look at the comments, there was no sign of it.

<comment><USER10> Happens far too commonly. I'll see a great link in the RSS feed and come to look for discussion about it after reading, but the article will have been removed. I've learned to search site:ycombinator.com with the article's title in order to track it down and see if there was any discussion before it was binned.

</comment></comment></comment><comment><USER11> What a travesty of both justice, democracy, and government.

Too big to jail, I guess. Ignorance is an excuse when you have a president running interference for you to undermine democracy, even if you knowingly and intentionally weakened and exposed the whole country and then lied about it and played it off.

But let's make a crooked, incompetent, and dangerous person our leader.

<comment><USER12> Honestly, the 2016 presidential election really does feel like the 1996 Simpsons Halloween special. (only without bothering with the meat-suit disguises)

It's a two party system; you have to vote for one of the green tentacled monsters.

Don't blame me, I voted for Kodos!</comment></comment>


How Russia and China Could Strike the U.S. Air Force's 'Achilles Heel' - <AUTHOR> https://warisboring.com/how-russia-and-china-could-strike-the-u-s-air-forces-achilles-heel-e3d61d2a8f7e#.vm3zvwjpf <comment><USER2> There will be no strike at anyones achilles heel, at least not if we are talking about mayor world powers like the US, Russia and China.

The most any one of these powers will do (and all of them do it) is trying to subvert and destroy weak governments that are friendly to the adversary.

There's not even a chance that one power might try to pit the two others against each other (I'm talking about a real war) because all of them are guaranteed to wipe out all of the others if the survival of their own state is sufficiently threatened.

The reasoning for this goes something like this: If we are destroyed and only one superpower survives this (because they didn't take part in it) they'd be in a position to dominate all of what remains. Very cynical but that's how MAD works.

Even Israel which is much weaker than any of those three has a similar deterrence strategy. It entails striking the West, even if they were overrun by Arabs, not Western powers.

[https://en.wikipedia.org/wiki/Samson_Option](https://en.wikipedia.org/wiki/Samson_Option)

I don't like how this all works (I'm not a Sociopath) but it seems to have been very effective over the last decades because the actors were all rational.

The reason why Muslim countries acquiring WMD's is so much more heavily opposed is that many strategists do believe that their ideology could threaten MAD. It is not inconceivable that some of these governments could launch an all out attack if they had the capability believing that they will all go to heaven for taking out what they perceive to be "the great Satan".

<comment><USER3> We don't "like" MAD because on the narrative plane, it's a disgusting concept. Still, here we are.

This depends on whether or not you believe the ideology can travel past the level of technological sophistication necessary to deploy nukes. The ideology itself is pretty self-abnegating - it has many marques of a suicide cult.

This being said, there was this weekend ( from Aug 18th, 2016 ) a repeat of Douglas Cohn's "WW4", in which one nightmare scenario is ISIS "invading" Pakistan and becoming nuke-capable.

I imagine that'd get our collective attention if it looked like it was forming. I hope somebody is paying attention...

Cohn also notes that, at least in the offensive role, one division of American troops could dissipate ISIS in short order. After the offensive comes the "you broke it, you bought it" part, which is why we don't just.

<comment><USER2> There is no definitive proof for US contingency plans but the US is so heavily involved with Pakistan to secure these nuclear weapons and on top of that there have been so many statements of top US officials (even from US Presidents) regarding this issue that I'm 100% sure that there are plans to swiftly take out or otherwise secure these nuclear weapons if something dangerous develops there.

[https://en.wikipedia.org/wiki/Pakistan_and_weapons_of_mass_d...](https://en.wikipedia.org/wiki/Pakistan_and_weapons_of_mass_destruction#U.S._security_assistance)

Note how the government of Pakistan responds to these allegations that the US has these plans by reassuring everyone that the weapons are safe instead of being outraged that a foreign government disregards their sovereignty in such a way. That says a lot.

> This depends on whether or not you believe the ideology can travel past the > level of technological sophistication necessary to deploy nukes. The > ideology itself is pretty self-abnegating - it has many marques of a suicide > cult.

Well ISIS is quite comfortable with using the latest technologies for their purposes and countries like Iran have a truly remarkable scientific community (considering their isolation), so I tend to believe that ideology alone will not inhibit them sufficiently to not being able to achieve this goal if they really want to.

Edit: Yes I agree, the US could take out ISIS in a few weeks, so could Russia. What is missing is the will as there are serious repercussions if you try to do it while other superpowers oppose it vigorously. (and on top of that you'd have to use very blunt force in order to do it - many civilians on ISIS held territory would die)

That's why I believe that Trump as a president would make it happen as he has stated on multiple occasions that he would do it together with Putin in some way.

If the US and Russia / China shared a common goal here they would destroy ISIS very quickly.

<comment><USER3> I agree - I didn't chunk the pieces of the ideology itself very well. It's a dissonant mix and I can't always parse it well.

Iran is a... bicameral society with, as you say, a high degree of sophistication coeexisting with fundamentalism. As the sting of 1953 fades, I can't help but think we'll eventually achieve normal relations with them. I don't, for example, see as much screaming about the Obama Administrations attempts to thaw things out by the Rightist press as I used to. It's not a stretch for present-day Americans to denounce Dulles-brothers style adventurism.

This being said, I think of ISIS itself as an international attractor for disaffected youth, with an apparently _explicit_ emphasis on martyrdom.

And yes - I expect we'll keep a very close watch on Pakistan. I just meant that if Pakistan were to fall, it wouldn't be a huge military effort to ... secure it. It would be a big logistical effort but I think of Gulf War I as the model. Of course, then we'd stiffen the resolve of those who oppose Westerners being there at all. I am also sure that we'd try to use the fig leaf of the U.N.

</comment></comment></comment></comment><comment><USER4> Yet another alarmist article that ignores the fact that China, Russia, and the US could never engage each other in any meaningful capacity without sparking global nuclear armageddon. No, we do not need to spend hundreds of billions of dollars to fix this "problem."

<comment><USER5> Well, that's a bunch of ignorant baloney.

If Russia and China have these capabilities today, then opponents we DO engage will have them tomorrow... unless, you know, someone fixes the problem.

Not to say that we have nuclear assurances against a direct conflict between the US and Russia, we don't have such assurances for US proxies engaging Russian or Chinese proxies. The US needs to have enough conventional deterrence to prevent major proxy wars - which, by the way, destabilize the world economy and make the world a crappier place for everyone, including the "third-world-lives-don't-matter" isolationists such as yourself.

</comment></comment><comment><USER6> "Could"

But they won't. MAD is alive and well, no matter how insane it is.

<comment><USER3> For something so ...cognitively dissonant, it sure has been effective. I stick with "the game theory of MAD is ironclad."

</comment></comment><comment><USER7> ... and if you only invest in this particular area (with a leading American country giving jobs to Americans, where it counts) with 50 billion USD, you could protect yourself! Would you like to learn more?</comment>


Ask HN: Real-time log viewing - <AUTHOR> The powerful solutions seem to focus on post-hoc log analysis. The thing I'm working on produces a lot of logs. Logs that I like to look at when debugging. Viewing them is a bit overwhelming.
I'd like a viewer that:
-filters by JSON properties
-formats JSON logs into human readable messages
-can fold large messages
-lets you save sets of filters
-lets you simultaneously view the same set of messages using different filters
Right now I settled for splitting logs into different files based on filters. Which is okayish but doesn't work well for teammates. And even at mediocre volumes Emacs will choke. <comment> java-man \- are these files local or remote?

\- do you need tail?

\- could you provide a link to a typical log file (with sensitive info removed of course)?

<comment><AUTHOR> They're local, the logging logic is completely under my control, I'm fine with piping it to wherever as long as it does what I want.

For example the simplest JSON message would be:

      {"timestamp":"2018-06- 29T17:25:47.857Z",
      "module":"main",
      "msg":"[\"trying to reconnect\"]",
      "level":5}

while the human-readable representation for the same message is:

      global 17:06:067 trying to reconnect

So I'll have one main log file that gets everything in JSON, but that's only useful for post-hoc analysis. I can control what makes it to stdout at runtime but that's just a single view. So right now I've hard-coded the logging to spit out human-readable messages to different files based on the module and level properties. I open the files in auto-revert-tail-mode (emacs).

Not sure what you mean do I need tail? If you mean the tail program then yea that's what I effectively do at the moment. If you mean always seeing the latest logs as they come in - yes.

So the ideal software would just read that one file (or db) that has everything in JSON (or machine readable format) and let you have different "views" over the same data. Packaged in a nice (web?) GUI.

It shouldn't be too hard to implement but I'm hoping there's something out there already.

<comment> java-man There is probably something out already -

[https://softwarerecs.stackexchange.com/questions/37881/log-v...](https://softwarerecs.stackexchange.com/questions/37881/log- viewer-with-json-support)

[https://github.com/gistia/json-log-viewer](https://github.com/gistia/json- log-viewer)

[https://github.com/brocode/fblog](https://github.com/brocode/fblog)

I am currently writing a log viewer / terminal combo for internal use. Handling milti-line json with tailing is a bit of a challenge though.

<comment><AUTHOR> Oh I put the newlines on HN for readability, the actual logs don't have that. There are numerous tools that handle json logs on the cli, for example there's jq so you could

      tail -F my.log | jq <filter>

This is okay, but changing filters isn't trivial, running the commands and displaying side-by-side isn't trivial etc etc.

So say you can develop a decent emacs workflow using that, but once you get a new dev you cannot really pass it on. And if they're not much of a cli person then yea...

Thanks for gistia/json-log-viewer I'll check it out, though it doesn't seem to solve that much it's still interesting.

There's some nice Kibana stuff out there, but it seems single-view-at-a-time focused too</comment></comment></comment></comment>


Mobile web, app, or device? - <AUTHOR> http://www.pointsource.com/blog/mobile-web-app-or-device <comment><USER2> "There is unfortunately no perfect formula, but I thought I could provide some logic around how to make a decision."

If YourCompany.name == "Google"|| "Apple" || "Facebook" || "Adobe" || "Microsoft" || $Bank.name

then

MakeApp()

else

MakeWebsite()</comment>


AWK-ward Ruby - <AUTHOR> http://tomayko.com/writings/awkward-ruby

<comment><USER2> If this article has made you more curious about Awk itself, I highly recommend _The Awk Programming Language_ [1] by Aho, Kernighan and Weinberger. It's a terrific book all around (look at the list of authors), and Awk really is worth knowing if you use the command line a lot. (Credit where it's due: silentbicycle always recommends this book, and I read it on his advice. But I seem to have beaten him to this thread.)

[1] <http://cm.bell-labs.com/cm/cs/awkbook> (This link seems dead at the moment. I'm very much going to hope that's temporary.)

<comment><USER2> It's just a bit too late to edit, but the Bell Labs link is already working again.

</comment></comment><comment><USER3> It's nice to see an article that focuses on the common strengths of programming languages, and what came out of them, instead of the usual X vs. Y content. There is often so much common ground (especially between dynamic programming languages) that many solutions and knowledge are easily transferable and could be shared as well, independent from actual code.

</comment><comment><USER4> Didn't know Ruby (and Perl?) had BEGIN and END... pretty cool. However I would just write the final example as:

curl -s <http://www.gutenberg.org/files/1080/1080.txt> | tr ' \t' '\n\n' | sort | uniq -c | sort -n

and avoid any kind of procedural programming.

<comment><USER5> _Didn't know Ruby (and Perl?) had BEGIN and END..._

Along with BEGIN & END there is also UNITCHECK, CHECK & INIT in Perl: [http://perldoc.perl.org/perlmod.html#BEGIN%2c-UNITCHECK%2c-C...](http://perldoc.perl.org/perlmod.html#BEGIN%2c-UNITCHECK%2c-CHECK%2c-INIT- and-END)

These named blocks are used under the hood in Perl all the time. For eg.

        foo();  # => bar
        sub foo { say "bar" }

The above works because the last line is _interpreted_ as:

        BEGIN { *foo = sub { say "bar" } }

And so is compiled before the _foo()_ line is reached/run.

PS. Perl6 goes even further and calls them _Phasers_ : <http://feather.perl6.nl/syn/S04.html#Phasers>

</comment></comment><comment><USER6> Blocks come from smalltalk too: [http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.htm...](http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.html#Blocks)

<comment><USER7> Blocks are also available in Perl, in the form of anonymous subroutines. They follow Perlish conventions for argument handling (rather than having a neat inline syntax like Smalltalk or Ruby), but they're most definitely the same thing!

      my $block   = sub {             say "w00t, blocks!"   };
      my $closure = sub { $block->(); say "w00t, closures!" };

You'll have to look further for something Ruby does that Perl doesn't :)

<comment><USER6> Yeah, smalltalk blocks are almost identical to ruby blocks.

Article just acted like that was a ruby invention (which they corrected)

My comment had nothing to do with perl.

<comment><USER7> I probably should have replied to rtomayko's comment rather than your own. I'd edit the tree, but it's immutable!

</comment></comment></comment></comment><comment><USER8> Awk is one of those languages in which learning the syntax almost automatically teaches you to think differently. In Awk's case, in terms of tables, maintaining state between rows, and phases in execution while processing data. I find it as much as a mind f __* as Lisp or Prolog, though in a very workaday unixy sort of way.

<comment><USER9> I feel there's often too much focus on the execution phases in introductory texts. I've done quite a bit of scripting in a proprietary derivative of AWK (primary difference: multidimensional arrays and structs) and I've never used the execution phases in any of those scripts. I really don't see them as an inherent, defining part of the language.

</comment></comment><comment><USER10> This is very cool. It sort of ruins the approach I use when teaching people to program in Ruby or Python where I have them write some code to calculate stats on a text file then show them how trivial it would have been in awk.

</comment><comment><USER11> Similar Perl/Awk syntax for Python one-liners with BEGIN/END: [http://code.activestate.com/recipes/577075-pyliner-script- to...](http://code.activestate.com/recipes/577075-pyliner-script-to-run- arbitrary-python-code-on-the/?in=user-4119417)

<comment><USER3> The -e is what tells perl that "this is code, not a filename." One I regularly use (with perl) that doesn't seem to be mentioned yet is -p -i -e to inline modify files line-by-line. This is very nice for global search/replace actions on files found via find, grep or ack.

<comment><USER2> Yup, -i is very very useful, though I prefer to always call it as -i.bak (=> do the edit in place and make a backup of the original file as "filename.original.bak"), in case I do something hideously wrong.

For what it's worth (you may know this but maybe not everyone does), Ruby also provides the -i flag.

</comment></comment></comment><comment><USER12> Nice article. I use AWK and sed all the time. I still prefer writing some piped shell commands in one (sometimes lengthy) line than proper perl/python/ruby script, unless it's really needed. Why? It (paradoxically?) seems more natural to me in shell environments (and often can be done much more quickly that way).

Example of AWK usage from my old (currently unmaintained! and insecure!) pcspk project (<http://download.przemoc.net/pcspk>) is "Siemens ringtone converter": <https://gist.github.com/943386> (actually it requires gawk, which has nice extensions)

</comment><comment><USER13> This is both the most useful and engaging introduction to AWK that I've read _and_ the most intense deprecation signal by showing how to (almost drop-in) replace it with Ruby or Perl, which creates a terrible conflict in me.

 _"print $1"_ was the most I ever used AWK. So when I read the first part (whose examples made great sense to me) I shouted "AWK is awesome! I should learn it now!". Then the last part came in and showed me how I could use a language I already know to precisely replace it. I both feel compelled that I can leverage my current knowledge right now to solve another class of problems, and sad not to learn a completely new thing.

</comment><comment><USER14> Primitive network calculator I once wrote in awk:

<https://gist.github.com/7bb70e1065f085b46a00>

</comment><comment><USER15> I dare to suggest using $;=/[^a-zA-Z]+/ in the BEGIN block, then you can get away with using only split.each on the second line, and it's more perl-awk-ish :)

<comment><USER16> Even more perl-awk-ish would be to use the -F and -a switch and move the regexp onto the command line, eg: <https://gist.github.com/942975>

</comment></comment><comment><USER17> Is it just me or is the video of the talk at <http://shellhaters.heroku.com/> broken?

On closer examination I noticed the video is here [http://confreaks.net/system/assets/datas/1177/original/363-g...](http://confreaks.net/system/assets/datas/1177/original/363-gogaruco2010-the- shell-hater-s-handbook-small.mp4)

</comment><comment><USER18> Simplified C++ inspired by AWK: <http://github.com/lvv/scc>

</comment><comment><USER19> Isn't there an AI course taught somewhere that only uses AWK? Sure I remember reading about that somewhere.

</comment><comment><USER20> It's Awk, not AWK.

So 'ruby -n' acts like Awk? Neat.

<comment><USER21> GNU's is "Awk" but the language and most early implementations are referred to as "AWK" from everything I've read. More here:

<http://en.wikipedia.org/wiki/AWK>

<comment><USER20> Huh, I think you're right -- thanks for the correction. Maybe they ought to follow LISP's example, though!

<comment><USER21> FWIW, I was copied on an email exchange with Brian Kernighan regarding the piece and he referred to AWK as "Awk". Thought you'd like to know :)

<comment><USER20> Heh. I'm trying to remember how it appeared in A, K, & W's book: was it 'AWK' with the W and K in small caps? That'd explain the confusion. There's a copy on its way to me now. (It's a surprisingly great book.)</comment></comment></comment></comment></comment>


Dependency Injection for Python - <AUTHOR> https://github.com/google/pinject.git <comment><USER3> I don't get dependency injection. I come from languages that I am told don't have it. But when I read the Wikipedia page for DI, I get:

"a dependent consumer

a declaration of a component's dependencies, defined as interface contracts

an injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interface on request."

Wait, I still have to declare dependencies, just like the import statement in python, require.js in JS, etc. which are apparently not 'dependency injection' systems? And this just adds, er more code?

That same wikipedia page mentions dynamically loaded dependencies while also mentioning 'a declaration of a components dependencies' which sure doesn't sound dynamic to me.

Does anyone care to provide a better explanation of what dependency injection gives me over the existing common dependency mechanisms?

<comment><USER4> Python itself has DI built in throughout the stack.

Building Java like DI mechanisms is cargo cultism. The whole point of DI in Java is to work around its static typedness, so one can perform runtime binding of components in a dynamic manner.

Three quarters of cool Java and .NET "design patterns" are just band aids around semantic limitations of these languages.

<comment><USER5> > The whole point of DI in Java is to work around its static typedness.

So, coding the configuration of your application is an ideal way to work. Interesting.

<comment><USER4> Yes!

[http://thedailywtf.com/Articles/Soft_Coding.aspx](http://thedailywtf.com/Articles/Soft_Coding.aspx)

If Java guys wouldn't have stuck their heads up their asses so hard, they could use something like scripting language, with the whole debugging and library stack to configure their applications instead of building byzantine XML based DSL's.

Frankly my python (code!) based config files work a lot better than similar XML based config files in Android. Except mine are debuggable and readable.

The whole point of software is that it gets changed on demand. That's why it is called SOFTware.

Edit: Or perhaps you are going to enlighten me why XML config files are not code? Then you might be able to explain where configurations cross the border of "code". Is configuring Sharepoint coding or configuring?

<comment><USER5> Readable to who? Machine readable? Which is easier to change or debug: dependencies which are in predictable locations OR buried within your source code? Could you say the same thing about arbitrary python code? Now I have to learn the way _you_ decided to implement what's already been done dozens of times before I even get to reading the actual logic of the application.

Also, for the record, if you're debugging the infrastructure of how objects are created, you're doing it wrong. You probably don't understand the framework you're working in.

<comment><USER4> You are missing the point. I am not saying that one should make mess of his code.

I am merely saying that configuration files are code too. They need to be tested, debugged and refactored. Writing code in XML seems a retarded way to go about it. If my language would prevent me from writing configurations in itself in a sane manner, I would rather use another language with a solid toolchain for this part of the job. Than go and build my own DSL in XML of all things.

If you are of an open mind, go check how Django is configured and extended and compare it to your run of the mill enterprise framework.

And let me tell you that I did my fair share of enterprisey "configurable and extendable" framework shit. And its all a lie. You cannot make "simplified" languages that will enable you to be more "flexible" or to let amateurs to program system behavior. Always these kinds of interfaces gobble up way more developer hours than they save in the long run. Often programmers resort to writing programs that offer a sane API for writing these kinds of configs.

One should simply build a quality API and document it well.

</comment></comment></comment></comment></comment></comment><comment><USER6> _sigh_

DI is not the same as an IOC container. Get it right ffs, if you want people to take you seriously.

DI:

        class Blah():
          def __init__(self, dependency):
            self.dep = depedency

IOC:

        my_blah = container.resolve(Blah)

Anyway, onto my main complaint:

        "Pinject is a pythonic dependency injection library. Python ports of other libraries, like
         Spring or Guice, retain the feel (and verbosity) of being designed for a statically typed
         language. Pinject was designed from the ground up for python."

Wow, I'm impressed. Designed from the ground up for python. That's why you needed ~20 pages of documentation on how to use it?

Intuitive.

Also, what's wrong with annotations? I'm rather fond of this sort of code:

        ### implements, resolve, Scope
        class IType(object):
          prop1 = None
          def call(self):
            pass

        @implements(IType)
        class ImplType(object):
          prop1 = "Value"
          def call(self):
            pass

        scope = Scope()
        scope.register(ImplType)

        @resolve(scope)
        class UsesType(object):
          def __init__(self, t=IType):
            self.t = t

        instance = UsesType()

Or in pinject:

        obj_graph = pinject.new_object_graph(binding_specs=[SomeBindingSpec()])
        needs_provider = obj_graph.provide(NeedsProvider)

But wait, I want a test. Ok~

        instance = UsesType(my_mock)

Or in pinject:

        ??????

In fact, pinject doesn't even mention tests in its documentation. Whew~ That's only _the whole reason for using DI in the first place_.

Self important library is self important. Not amazed.

<comment><USER7> "IOC: my_blah = container.resolve(Blah)"

That's not IOC. That's service location. Which is only used at the "composition root" (look it up) in IOC.

"In fact, pinject doesn't even mention tests in its documentation. Whew~ That's only the whole reason for using DI in the first place."

No, testing accounts for just one of the more minor reasons to be using DI.

<comment><USER6> I would argue the single _greatest_ benefit (possibly, only benefit) that DI provides over other service location options (eg. factories) is that you get a nice means to test independent units of code by providing mock implementations.

In dynamic languages with no real 'private' members, the benefit is actually pretty minimal because you can assign mock service instances after the object is created.

eg.

        test_instance = Blah()
        test_instance.service = MockService()

vs.

        test_instance = Blah(MockService())

...which means, there isn't a lot of point in using it, unless you're using an IOC container which gives you some other synergy bonuses like singletons, per thread and per request instances, configuration file driven implementation binding, etc.

<comment><USER8> The direct opposite of Dependency Injection is the Service Locator pattern.

        my_blah = container.resolve(Blah)

Notice how there is no injection of dependencies at all.

I think you aught to learn what DI actually is... when you say that "the single greatest benefit (possibly, only benefit) that DI provides over other service location options" you are saying that DI is a form of service location (sic), which isn't the case.

<comment><USER9> > The direct opposite of Dependency Injection is the Service Locator pattern.

You're right in spirit, but the direct opposite of dependency injection is obviously direct dependency construction, not service location.

Service location is one step up from direct dependency construction, and can be enough for a lot of cases, but as you say, it's not dependency injection.

<comment><USER8> _You 're right in spirit, but the direct opposite of dependency injection is obviously direct dependency construction, not service location._

Fair call!

</comment></comment></comment></comment></comment></comment><comment><USER10> The author could refactor the documentation a little, starting with removal of the word "Pythonic" and perhaps ending only after 90% of the text has been replaced with a single section entitled "WHY GOD WHYYYYY".

        def python_di_copyright_2069_hosay123(dep, *args, **kwargs):
            modname, _, classname = dep.rpartition('.')
            mod = importlib.import_module(modname)
            return getattr(mod, classname)(*args, **kwargs)

> Though Google owns this project's copyright, this project is not an official > Google product.

We just published it under Google's Github to give a terrible project implied legitimacy that it likely doesn't even have internally.

</comment><comment><USER11> I understand dependency injection, but I never understood dependency injection frameworks. For me the whole point of DI is explicit composability. There should only be a few well defined places in my application where all my classes are assembled into a working program. If my classes cover my domain nicely, I should be able to compose all kinds of programs (including tests) and reuse code.

If my objects get injected to each other automatically by their name then my dependencies are just as predetermined, which results in coupled code, except the coupling is now difficult to read or modify.

Once I decided I am only using explicit injection, I don't need a framework, I just instantiate my classes in the right order and pass them into each other. What can possibly be more pythonic than that?

I have the same issue with Angular.js btw. They are trying to make is easy to start by adding dependency injection magic, but in reality all I see is "this can't possibly work (and indeed it doesn't)", so I just need to spend more time digging and understanding the magic before I can start writing ANY code.

Every documentation should start by explaining the explicit way of doing things, then adding the sugar afterwards.

import this

<comment><USER12> I'd prefer by type to by name, but there's still a small decoupling advantage: suppose you have some componentA in your application and you want to add some more functionality that depends on some serviceB. What DI should make possible is you modify only componentA, to state that it now depends on serviceB, and as long as you have a serviceB available then you don't need to change your "wire up my application" code at all (but of course if there is no serviceB then this should fail as fast as possible and tell you to fix it).

/has just written a compile-time DI framework in scala using type-level programming. It's pretty sweet except for the compile times.

<comment><USER13> > What DI should make possible is you modify only componentA, to state that it > now depends on serviceB, and as long as you have a serviceB available then > you don't need to change your "wire up my application" code at all

So... instead of modifying just the "wire up my application" code, you modify just the componentA code. In return you get to fill your code with magic so nobody can see where serviceB is created.

<comment><USER12> You always have to modify componentA - you're adding a new feature to it, and declaring that it takes a serviceB. If you're not using DI you have to change your "wire up my application" code as well.

The choice is between writing the wiring code yourself, which means a lot of boilerplate that's basically irrelevant to the functionality of your application, or have it happen implicitly, which yes involves a certain amount of magic. But even polymorphic functions are "magic" on some level.

<comment><USER14> In practice, the automatic "wiring-up" often breaks, and in any sizable system it quickly becomes very difficult and time consuming to track down and fix such breakages.

Things can become even worse when the libraries or frameworks you're using end up having bugs in them that interfere with the dependency injection they're performing.

Too many times I've seen very experienced and capable developers lose hours, and even days in some cases, dealing with dependency injection issues. Just one of these incidents, which will happen in any serious project, will far exceed the time and effort it would've taken to write the equivalent code by hand.

</comment></comment></comment></comment></comment><comment><USER15> Dependency Injection (DI) and Dependency Injection Containers (DIC) are the "in-thing" in PHP at present, and to speak against them [0] is - <USER2> disagreeing with anything fanboys latch onto - ridiculed, without a sensible discussion or explanation.

From a testing perspective I sort-of get it; from a "this is less tightly coupled" I don't: all you've done is move the coupling to a different level. Code always has to be coupled at some level, so where's the advantage?

With the amount of noise about DI I'm sure it's something I should pay attention to rather than be turned off (as happened with Rails), but I really don't et it. Can anyone provide the missing piece in my thinking?

[0] [http://till.klampaeckel.de/blog/archives/154-Dependency- Inje...](http://till.klampaeckel.de/blog/archives/154-Dependency-Injection- Containers.html)

<comment><USER14> It's interesting to follow the flow of ideas among languages/platforms.

We've repeatedly seen concepts that were popularized by the enterprise Java crowd flow down to the .NET crowd, and eventually to the PHP crowd.

IoC and DI is a good example of this. It was extremely hyped within the Java community during the early- and mid-2000s. Then this flowed into the C# community, with it getting a lot of attention during the late-2000s and early-2010s. Now it has finally made its way to the PHP community.

An astute PHP user who recognizes this flow of ideas will look at how the trend has progressed within the Java and C# communities. What they'll see is that there has be movement away from IoC and DI. The purported advantages never materialized, but there was a lot of pain and bad code left around.

Many in the Java community have moved on toward simpler frameworks and techniques, or even toward a far more static JVM-targeting language like Scala. Many C# users have similarly started moving away to other approaches.

At some point, perhaps around 2016 or so, the PHP community will come to the same conclusions about the suitability (or lack thereof) of these techniques. After experiencing the problems first hand, they'll too move back to simpler, more explicit approaches.

<comment><USER15> Interesting, I had wondered if this was the case but don't know where to look in the Java/.NET community for current best-practices (or What's Currently Hot). Where should I look?

> Many in the Java community have moved on toward simpler frameworks and > techniques

What have they moved onto?

> At some point, perhaps around 2016 or so, the PHP community will

Oh so true :D

</comment></comment></comment><comment><USER16> _Pinject is a pythonic dependency injection library._

+

 _Implicit class bindings_

...ummm...

</comment><comment><USER17> Implicit class bindings sound like a really bad idea and hard to debug.

      Pinject creates implicit bindings for classes.
      The implicit bindings assume your code follows PEP8
      conventions: your classes are named in CamelCase, and
      your args are named in lower_with_underscores. Pinject
      transforms class names to injectable arg names by
      lowercasing words and connecting them with underscores.
      It will also ignore any leading underscore on the class
      name.

      If two classes map to the same arg name, whether those
      classes are in the same module or different modules,
      Pinject will not create an implicit binding for that arg
      name (though it will not raise an error).

</comment><comment><USER18> that looks pretty good.

not sure if i overlooked it in the notes or not, but i have a couple questions.

you mentioned copyright at the end. what sort of license are you releasing it under?

Does it support nested creation of objects? ( ie if you ask for an instance of class 'FOO' and FOO has a DI or 'BAR' will BAR be first created and then injected into FOO)

<comment><USER19> Seems like it's released under the Apache License 2.0 (cf. LICENSE file).

</comment></comment><comment><USER20> DI is about breaking constructor coupling. I wish people would understand that.

</comment><comment><USER21> Stop writing Java code in Python. No. Bad. Stop it.</comment>