Would be really interesting if people could add their location. Seems like those in US have really long journeys to work?
782 karma · joined June 6, 2011
> The only thing that can be said with any certainty, is that not doing any technical debt maintenance does impact them negatively. But there isn’t a lot of difference from that point on. This is slightly controversial, and could be unrelated altogether.
Judging by the lack of activity on this thread, and the above article, I think I could effectively argue that technical debt either doesn't exist (outside the minds of developers), or that it's 'a thing', but just not that important.
This isn't what I was hoping to see...
What I would say is that we at YJ feel very strongly that the future of work is freelance. We've (literally) put our money where our mouth is on this belief (not to mention our careers), and so we, and I'm guessing the others in this space, really want to work with the freelancer community to make this happen.
I've been a freelancer (developer), and a hirer (as CTO at various companies), so feel reasonably in touch with both sides of the market, and frankly, neither side functions properly. You (as freelancers) shouldn't be paying 20%, and employers shouldn't be wading through the cr^p that traditional freelancer recruiters put them through[1]. We're all working on making this better.
Whilst we're doing our thing, there are some great competitors in this market, and hopefully they would agree with me when I say please don't give up on us - the world of work is changing, and we're all trying to push it along in the right direction.
Oh, and one minor rebuff - the very best employers in London, certainly, are using online services, whether that be YunoJuno or any of the other sites listed - and whilst the names on the list may change, the migration to online services is inevitable. This is your future, get involved.
[1]There are exceptions to this - some recruiters are good guys - but they take a lot of finding.
* BitBucket (core app, private)
* GitHub (FOSS projects, public)
* Trello - tracking progress
* HipChat - IM
* Basecamp - dates, discussions, project type stuff
* Google - docs, shared calendars, Hangouts
* Screenhero - screen sharing
We've almost managed to remove email from our daily flow - I very rarely send / receive internal emails now.
HipChat + Trello have become our foundation tools - couldn't live without them. (The new Trello attachments view has plugged a gap, and made sharing designs much easier than it used to be.)
HipChat is brilliant once you move on to building stuff - plug in code commits, deployments, customer service (we have Zendesk alerts) etc.
I would absolutely agree with your last point - sharing links + discussions around links is the biggest problem by far - Google+ is a perfect fit, but (our) people just seem resistant to it. I've tried, and failed, several times to get everyone to adopt it. We have a bunch of iOS people and they often share direct from Flipboard, which may be part of it.
If you want a reason to use the instancecheck magic method, the mocking of test objects is a good one. I recently came unstuck with testing Django models and mocking out DateFields, and the instancecheck method was the solution - http://tech.yunojuno.com/mocking-dates-with-django
If you're interested they are always looking for both sponsors (which basically means giving up a meeting room in your office for the week, and providing lunch for the team) and mentors [2] - who can spend some time with the team helping them shape their idea. It's a brilliant scheme, and a really inspiring week.
[1] https://youngrewiredstate.org/ [2] https://youngrewiredstate.org/festival-of-code/information-f...
He's best known for being a good communicator, clear and concise, informative but never patronising. Which makes him quite a good 'patron' for a writing app.
They weren't that confusing - remember the original "dotcom boom" (and bust) was in the 90s, not the 2000s - and although it didn't end well, people were building high volume, complex, transactional websites in those days, and it wasn't all Perl scripts.
I was a MSFT platform developer at the time, and I remember being acutely aware of the rise of Java as the web development language in 95/96 - and the subsequent explosion in Java application servers and associated 'platforms' - Silverstream, ATG, Blue Martini etc.
The classic example is a list (in a strongly-typed language) - without generics you would create specialised strongly-typed list classes - you could have a StringList (only strings), an IntList (only ints), etc.
Using generics you can define a single list class of type <T>, where <T> is any type. Then at runtime you would create a List<String> or a List<Int>. Same outcome, less code, easier to maintain.
MSDN has a good intro to C# generics - http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).as...
They are less appropriate in dynamic languages, as type-safety isn't a compile time concern.
[UPDATE] According to Wikipedia (judge for yourself), Larry Page is quoted as saying:
"BackRub is written in Java and Python and runs
on several Sun Ultras and Intel Pentiums running Linux."
When we started YunoJuno we hooked up Sentry, as we are a django app, and it's the default option for error management (oh, and it had an Heroku add-on available). It's a great product, but I got frustrated early on with how it was aggregating errors - and ended up in a public StackOverflow confessional during which I unpicked the source and tried to work out what was going on (http://stackoverflow.com/questions/13331973/how-does-sentry-...).
I started using Errordite when it became available (I had to write the python client first!) and ran both in parallel for a couple of months. Both do a great job of helping manage exceptions, but the killer for us (and the reason we dropped Sentry recently) is that Errordite allowed us to determine the rules around grouping exceptions ourselves.
I won't say any more for fear of sounding like a plant, but in answer to those who have posted 'what's the difference' - it's (IMO) the ability to set custom rules around how errors are handled.
Are you working with FlightStats?
(Oh, and we're not charging you anything - we charge the employer, fixed rate, no shenanigans.)
To be honest, not having secrets under some kind of source control seems like a bad idea, as you just know that the reality is that they will be in an untracked spreadsheet somewhere.
One thing I would emphasise is the importance of HTTP - and whilst I wouldn't recommend anyone actually reading a formal spec from beginning to end, if you really do understand request-response mechanics it will underpin everything else you learn (which is essentially how to process requests and generate responses).