throwaway_ghj

I didn't claim either of those things.

I'm just speaking from the practical experience I have.

It's just that in static languages, you write unit tests more around business functionality. In dynamic ones you end up writing unit tests essentially for typing and stuff like that. And, you know, you have tooling so you can actually perform the refactorings at scale across the code base. Like real tools, that the rest of your team know how to use, and your business can hire another person from the same hemisphere to work with after you've moved on.

The tooling around static languages is generally stronger. I've written very similar types of code in both Java and Python, and hands down, I've found it easier to develop and maintain in big code in Java.

I still script quick stuff up in python for personal use.

YMMV.

I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. Also, on large code bases, I now prefer having real refactoring support.

I'd rather pick something on top of a compiler that is not brain dead.

If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.

I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.

Are those options the state of the art?

I wouldn't use either.

Edit: added the following...

I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. That gets old fast. Also, on large code bases, I now prefer having real refactoring support.

I'd rather pick something on top of a compiler that is not brain dead.

If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.

I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.

reduce the problem as much as possible... use a single serve espresso machine. Volume remaining and freshness aren't really a problem in that context.

The best kind of code is the kind that doesn't get written.

Just say "I really appreciate your time so far but I have other offers which I am more interested in and don't wish to continue any further with your interview process"

Just be polite and don't waste either your or their time any further.

maybe GnuCash. You'll have to check for features.

Or if it's not at great volume, you could just do it the old fashioned way. About $20 at your local stationary store should sort you out.

People become entitled like that, basically because you let them by repeatedly allowing them to take your time for free.

Compare with: "Sure, I'd love to do that. I can spend about 10 hours on that this week and that will cost you $1000. Who do I address the invoice to?"

That should sort the wheat from the chaff pretty quickly.

No, you're missing something.

hack a sports watch.

I imagine there are all manner of over-engineered solutions to this problem.

Is it ethical to just walk away from a problem?

There's definitely market segmentation and it's definitely a conscious decision, but there are other functional differences between the supermarkets. (Bigger package sizes at pak-n-save, and New World's are also located in more convenient locations).

So they probably got the market segmentation right. Compare with eg Four Square -> small, expensive, small selection, but still feels cheap.

I worked at New World when I was a kid and they definitely hired disabled and people of various cultures. I think this is reflective of the location of the particular supermarkets though. They are generally staffed with people from the local area so definitely represent the local demographic.

An IDE. The same as the technical people use.

(In what world can "non-technical people" build any kind of app?)

  * they are part of a big enough team that individual responsibility is removed
  * they're not given enough time to produce good quality code
  * the design came from someone without sufficient expertise, and the programmers "just built it"
  * they did the best given the time they had
  * it passed testing
  * programmers are generally not empowered to make go/no-go decisions
  * even if they did express concern they may not have been listened to
  * any internal challenges on ethical grounds were probably kept quiet and worked around

Usually with this kind of incident there are multiple process and quality failures, not just "why did the programmers not do better"

balsamiq.

Or my favourite, pen and paper.

Nike+ app. Use the built in coach (training programme). Half-marathon training, thoroughly recommended.

Don't eat junk food too.

Yeah but then you'd have to maintain some software built on web tech.

hands down one of the best software engineering articles I've read in a long time.

Balance. Take the long term view.

Your skills don't stagnate because you have the weekends off coding. No one is a 100% efficient human being [the word for that is robot].

My advice would be to set a baseline of working hard during work hours, but also develop habits and routines outside of work hours where you actually attend to the other things you want to do (exercise, hobbies, and socialising).

With that basic balance and limits in place, then you add a little bit more of the thing you want to excel at (in your case coding). By a little bit, I mean maybe an extra hour or two per day, if you have the time and energy.

Your big achievements will probably come from chipping away a little bit each day, and making whatever you work on a little bit better each time you work on it. Not from busting a gut when you are 23 and burning out by 25 [ignore my assumptions about your specific age].

PS, working for a conventional company can be very satisfying, you might just need to try a few different ones until something clicks into place.

> most coding is treated as a commodity by the business world, and the younger devs have a cost advantage over you.

I have an experience advantage of being able to ship working software that actually meets requirements. Unlike many younger devs.

BE(SoftEng) here. Professional 10 years. ~3 years at current employer who is the dominant IT vendor in my country. There are definitely lifers within this organisation, the pay and benefits and conditions are good.

I plan to broaden my horizons with philosphy and business studies and hopefully mitigate institutional boredom by growing my own side-projects until such time as this overtakes my salary.

Can't really see a masters being particularly useful.