karterk

although it doesn't seem to allow more than two people's cams at once.

More than 2 people works fine for me. Is anyone else facing this issue?

Sometimes, I am not able to distinguish between a missing mic/webcam and genuine webrtc connection issues so either could be a problem.

If you have daily stand-ups, why would you have 30 minutes worth of update per person?

This whole article is pretty extreme. Standups, just like any other process (light-weight or otherwise) is only good until its original intention is being served. If a standup is taking a long time, make it a point to cut it short. If someone is narrating a long story, ask that person to stop and take the rest offline.

Finally, everyone should understand that stand-ups are used to convey status and information about important things. It's not a recital of what each person did the previous day. Sometimes, you might have nothing to say and in that case, just say so. Nobody should be talking about details in standup.

On a larger note, I wish "managers" used other simple means like talking to people openly about their aspirations, instead of blindly following the processes laid out by the company. Thankfully I don't work in such a place - but most big corps could just do better on the attrition rate if they made their appraisal process more employee friendly, focussed on encouraging a open culture and reduced needless hierarchy.

1. When I already know what I'm doing and it's just a matter of coding what's already in my mind

2. When I'm writing in a dynamically typed language, it forces me to be not lazy and have adequate test coverage since I don't have compile time type safety

I do less of TDD when dealing with a statically typed language and/or when I'm working in an exploratory mode. TDD doesn't help me when I'm just trying out different things to get going.

The thing that pisses me off is when people don't realize that EVERY technique has caveats and try to promote it as a golden rule - a lot of "agile" consultants preach TDD as the golden grail for writing code without any bugs.

EDIT: grammar

1. While working on module 1, you realize you need something from module 2

2. Open module 2, add new feature and publish changes

3. Go back to module 1, test new feature and resume work

This process is fine once both modules 1 and 2 have matured but painful to deal with while the APIs are still taking shape. Hence it makes sense to keep a good abstraction between potential components and spin them off as an individual service only when they're stable enough.

The point about operator overloading is accepted, but this is not too different from what happens with metaprogramming in Ruby or say macros in lisp.

Even python has some quirks. See: http://stackoverflow.com/questions/1132941/least-astonishmen...

Can't speak for Heroku but with EC2 you get the ability to dynamically add/remove instances. While this seems like it's needed only for certain kinds of startups, the reality is that most background processing is batch oriented and it's extremely cost effective to just spin up instances when I need them, crunch the data and terminate them after that. And, if you go for spot instances (and use a fault tolerant framework like Hadoop to distribute jobs), it's becomes even more cheaper.

Going with Ruby (Rails?) is a sane choice from a development point of view, but a lot of shared hosts still only support PHP and a lot of my web design friends are comfortable only with basic FTP-ing. I remember reading some tweets from Jeff from last year, which hinted that he might be stuck with PHP for his next project (which I believe now is Discourse). Nevertheless, it's interesting that they did not go with PHP.

Edit: minor grammar

Programming.

Then apply this test: Will people pay you for it? Will they pay you a lot for it?

YES.

Okay, perhaps this post is not for me, but the post comes across as highly anecdotal. E.g:

That advice has probably resulted in more failed businesses than all the recessions combined...

I hate to ask it, but source?

B2B is hard in a different sense. You need to be involved enough with an industry to learn the way it works and get to know people who you can contact to sell a better product. If you're just starting out, it's going to be very difficult to get medium sized companies to take you seriously. It becomes easier if you already know the decision making person.

Ask, "how does Python already solve my problem?" and "What Python language feature most resembles my problem?"

This does not come across as a strong apology because Steve keeps stressing on making someone feel terrible and not really accepting that he was wrong to ridicule code without offering constructive criticism.

http://www.strangehorizons.com/2000/20001120/secret_number.s...

It has been submitted to HN a few times too.

[1]: http://9rules.com

* If you end up as a software engineer, building good software has a lot of things that fall outside core computer science concepts. Read up about unit testing, continuos integration and continuous delivery.

* Build, build and build. No amount of reading will help you tackle some of the issues that real-world data will throw at you. An active Github account also serves as a validation that you are actually capable of "shipping things".

* Breadth is important, but continue to focus on becoming great at atleast one thing.

* Learn a few languages. Pick one or two which are statically typed (Scala, Haskell), one or two that are dynamically typed (Python, Ruby). I also highly recommend Erlang which was a revelation for me.

* Master Git (or Mercurial, if that's your thing).

* Choose to work in companies where you feel you will be surrounded by people smarter than you. This is possible even outside the Googles and Facebooks of the world.

* Don't get overly attached to your tools. Languages, frameworks and editors are a means to an end. Be open to new ideas and better way of doing things. There is an initial learning curve before you start becoming truly productive in anything and so be mindful of that before you dismiss something.

* Lastly, don't get burned out.

In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.

It's not very fair to compare Scala with Clojure - static typing might not be everyone's cup of tea, but over time, I have come to appreciate it's power when dealing with certain classes of problems.

Reading theory and books won't get you far as you will realize that the real-world problems bring a lot of perspective that is not documented well enough in most books.

So, how do find a challenging problem to solve? Most people will suggest working on side projects, but some really hard problems (e.g. distributed computing) requires resources that make it impossible to pursue as side projects. Also, having people much smarter than you around you helps with the learning. So, the alternative in this case is to join a start-up or a big co just so that you get a chance to explore difficult problems.

I would suggest staying away from using JS as it affects genuine users as well (e.g. those who use screen readers).