martininmelb

While ack is a great tool, I don't think the author pointed out its strengths in this article. From my perspective, the strengths are using it recursively and its ability to 'recognise' files containing source code (and yes, I know that grep has a recursive option - it's more innate, though, in ack).

Are you confusing awk with ack?

I used to use IntelliJ when I programmed in Java and loved it. I was still learning Java and its ability to show help, check syntax and refactor was excellent. But then I did less Java and more Python and returned to vim. One issue was that I was not only editing code, I was writing documents in LaTex, I was editing large 'data' files (ascii text), I was editing blogs and other notes in Markdown etc. Unfortunately, IntelliJ seems to regard everything as a project and does not make it easy (at least back then) to simply create or edit a file that is not part of a particular project.

Another advantage of vim is that most of the time at work I am working on a PC but editing files on Linux boxes. At home I am on a mac. I know I could run X, but I prefer running Putty, and I enjoy the lightweight nature of just bringing up vim. So, currently, vim is my editor of choice.

Also, I must admit that after 20+ years of using vi/vim, I still make the occasional mode mistake and type 'i' when in insert mode, or ':wq', but vim is still my favourite editor.

I'll try to summarise in two words: "Technical Debt".

These articles reinforce something that someone told me a long time ago about a study about interviewing.

1. In most cases, the person (or the person in charge, if it is a panel) makes a decision in the first five minutes of the interview.

2. The decision is based on how much the candidate resembles the interviewer (i.e. how similar they are to the interviewer in terms of personality and skill set).

I showed this to my 9-year old daughter. After explaining it to her, her first question was 'Can I have one?'. I told her that it was a one-off. She then asked me to bookmark the page for her.

I like the sentiments expressed in the post and hope that on my deathbed I will not regret "not having spent more time with my children".

I think, though, I would regret it more if on my deathbed I thought "My children did not get the opportunity to attend University because we could not afford it", or "If I had the money to send them to a better school, they may have had more opportunities".

I also would not like to be a burden on my children if I became sick because I did not have enough money saved to pay for medical care or whatever other care I need.

In my fifties, when there are redundancies, I don't want to be the one they say "while all the other workers are prepared to put in the hard yards, he's the one that always leaves at 5:00" or miss out on promotions because the others work longer hours than me.

This story about Steve Jobs is probably relevant:

I was sitting in Steve's office when Lynn Takahashi, Steve's assistant, announced Knuth's arrival. Steve bounced out of his chair, bounded over to the door and extended a welcoming hand.

"It's a pleasure to meet you, Professor Knuth," Steve said. "I've read all of your books."

"You're full of shit," Knuth responded.

(http://www.folklore.org/StoryView.py?project=Macintosh&s...)

I have always seen git as a kind of assembler language for version control. We are now starting to see some second generation languages built on git. The first batch may not be perfect, but over time we will see improvements.

I welcome these attempts to abstract git and make it more accessible. I haven't yet seen one that I think I would prefer over native git, but am looking forward to see what develops.

While I am sure that the author believes that this question drives his decision, the research indicates that most employers make a decision within five minutes - and the main driver of that decision is the extent to which the candidate is like the interviewer.

As an 'end-user' of Python, I rarely find myself writing my own classes, but I am really pleased that the authors of many of the libraries that I use decided to write classes.

I think the distinction between 'end-users' and people who make libraries is an important one and one that Jack seemed to overlook.

1. I notice your solution uses recursion (at least I assume it uses recursion - I am not a ruby programmer). I think this would be an issue for large values of n (stack overflow).

2. I think an iterative function for fact would be more efficient.

3. I notice you do not memoize the result of fact even though you are calculating it twice for each call.

I suspect that you are trying to show how compact a solution can be, but in an interview situation, I would probably be more impressed by someone who is aware of the issues above.

Sounds like an early exercise in Agile Shipbuilding.

Don't express appreciation, show appreciation. What do I mean?

Express appreciation: Hi Jane, I really appreciate that you worked until midnight to get rid of that bug.

Show appreciation: Hi Jane, I looked through the code - and you've really improved it by replacing that buggy lookup with a hash function.

Anybody can do the first and it does not take time or effort. The second shows that you've taken some interest and taken the trouble to understand what they've done.

I came here to say exactly the same thing... so, here's my other piece of advice: Think about very good managers that you've had; what was it that made them good managers? Try to emulate that (for me it was the weekly 1:1).

It's both.

Which is also what the company is claiming to do. I.e. we will create a prototype and walk you through it before we start coding.