jobs-discuss

Job hunting, interview process and anything related to the experience of a job writing the Clojure language.
2019-05-09T01:49:47.033600Z

For those who’ve worked in start-up environments, I’ve got a question for you. I’m told “Well, early-stage companies ship crap software - that’s just how the game goes. Once they’ve landed funding, then they can slow down, rearchitect the system, write tests, write a CI/CD pipeline, etc.“. This seems bonkers to me. How common is this? Is it really the norm, or are there startups that “measure twice, cut once”?

seancorfield 2019-05-09T05:53:17.035100Z

@d4hines I would expect there are some startups that do indeed Do. It. Right. but I've seen a lot of startups that build a proof of concept as fast as possible to pitch to VCs and that ultimately becomes the first production version of their system 😞

seancorfield 2019-05-09T05:55:58.035900Z

A lot of startups have very toxic work environments in many ways. You couldn't pay me enough to work in a startup again!

dominicm 2019-05-09T07:18:32.037400Z

Tests and CI aren't that useful in my opinion. At least I've not missed them on clojure projects where they're missing and we are rushing for the early parts of a project.

4😮
alexlynham 2019-05-09T07:53:04.038200Z

CD > CI

alexlynham 2019-05-09T07:53:48.039100Z

but CI is still nice. If it’s my project they’re there from day 1 just because it’s easier to set that stuff up with sensible defaults when your project is tiny

1💯
vemv 2019-05-09T08:30:06.042400Z

Generally there's a false dichotomy between agility and testing, paricularly between those who aren't proficient in the latter I've added test suites where missing at various startups (size 3 to 50) and never it was a rejected proposal or delayed the roadmap. So I'd try gradual introduction of best practices. If they are flat-out rejected I'd run away since that CTO is likely to make my job miserable in more than one way

nilrecurring 2019-05-09T09:22:10.044300Z

The test suites on our services save my day roughly once a week, but YMMV

gklijs 2019-05-09T09:44:48.045600Z

Being quick to market makes sense for a start-up, but so is a plan to eventually make it sustainable.

3Jane 2019-05-09T09:44:58.045800Z

I think it’s pretty common

3Jane 2019-05-09T09:45:46.046600Z

but then again standard advice for startups is “do things that don’t scale”, including founders fulfilling orders, humans augmenting “AI” and so on

3Jane 2019-05-09T09:46:15.047100Z

the thinking is, most of the time you don’t even know whether people will buy your thing so there’s no point building an actual thing until you get proof

3Jane 2019-05-09T09:47:14.047800Z

I don’t think there’s anything wrong with building a prototype / proof of concept, as long as the founders are aware it’s a PoC and it will need to be rewritten from the ground up

3Jane 2019-05-09T09:47:50.048500Z

except the concept of a prototype doesn’t seem to exist in the agile world, and so people are left polishing a turd, and understandably angry about it.

kwladyka 2019-05-09T11:57:47.051200Z

I would say it depend on your ops experience (I feel ci / cd are using wrong all the time by people, personally I call all this things ops). If you are able to create good deploying and testing environment you are doing this. If not you are not doing this on the beginning.

kwladyka 2019-05-09T11:58:15.051800Z

In world of containers and kubernetes it probably matter more than ever

kwladyka 2019-05-09T11:58:39.052300Z

but it is really hard to do it right, you need experience

kwladyka 2019-05-09T11:59:10.053200Z

If you will do it wrong, then it will be an issue instead of solution

kwladyka 2019-05-09T12:02:21.055500Z

I am doing both Dev in Clojure and Ops, because I like it and I see it as whole picture. With Ops experience I can solve things simple and easy on different level when I can’t do it simple on Dev level.

kwladyka 2019-05-09T12:02:39.055800Z

Personally I see huge benefit from it

kwladyka 2019-05-09T12:02:54.056200Z

But it took me a lot time to understand how to do it right

kwladyka 2019-05-09T12:04:07.057100Z

From my experience most of Dev don’t have high Ops experience, so complex tools for Ops can make issues for them

kwladyka 2019-05-09T12:04:25.057400Z

they don’t understand them and don’t want to learn them

kwladyka 2019-05-09T12:06:12.058100Z

so on the end you need whole spectrum of experience in team

kwladyka 2019-05-09T12:07:07.058900Z

And it is really not about startups only, it is easy to do it wrong in all sizes of companies 😉

kwladyka 2019-05-09T12:08:13.059500Z

Summarising up: Personally I am doing Ops for all my Dev work, but I feel comfortable with it

kwladyka 2019-05-09T12:11:28.060300Z

Answering your question: I would depend Ops things on early stage on team experience

2019-05-09T12:16:41.064400Z

Appreciate the input as always 🙏

trevor 2019-05-09T12:38:23.071500Z

I’ve grown two Clojure teams from back of the napkin ideas into self sufficient businesses. This my 2 cents. The priorities and incentives for a startup and established business are drastically different. In a startup you’re basically trying to survive — looking for the next client, trying to raise that next round, etc. You’re doing your best to make every dollar count and in most tech startups, the most expensive thing is development. It’s more valuable to ship something imperfect now than a perfect something later. It’s a tradeoff between cost and time. Of which, startups don’t have much of either.

trevor 2019-05-09T12:38:55.071900Z

That being said, being in a startup doesn’t preclude you from writing quality software

trevor 2019-05-09T12:41:14.073300Z

Re: quality - if I were to do another startup, I would put more emphasis on quality test suites. Functional, integration, e2e, etc.

trevor 2019-05-09T12:41:55.073900Z

They allow you to move much quicker with more confidence

6👍1💯
dominicm 2019-05-09T18:59:56.077300Z

My problem with tests at early stages is that you're still exploring the domain. You can't test anything to do with the domain, because it will change constantly.

dominicm 2019-05-09T19:00:15.077900Z

This is hard to discuss without clear timeliness of the stages we are all comparing though.

kwladyka 2019-05-09T19:01:12.079100Z

This is another topic, detailed unit tests don’t make too much sense, we want to test general ideas and functionality and critical flow

2019-05-09T19:01:26.079500Z

A timeline that makes sense in my mind: before customers pay for it, it should have tests.

1👍1💯
kwladyka 2019-05-09T19:01:56.080300Z

I would go even further and say there is a lot of things which we can really test only on production

2019-05-09T19:01:57.080400Z

I’m not discussing the merits of unit vs functional vs integration vs generative vs whatever testing.

kwladyka 2019-05-09T19:02:15.080800Z

especially when depend on third party systems

2019-05-09T19:02:17.080900Z

(Though I’d love to as a seperate topic0

kwladyka 2019-05-09T19:05:30.082200Z

But I think about tests also like about documentation of the system, when writhing them. To show how to use system in code

kwladyka 2019-05-09T19:07:04.084100Z

Description of custom business needs

vemv 2019-05-09T19:07:34.084900Z

Funny thing, right now I'm working on adding extra test coverage for something I merged 1 week ago i.e you can defer specific coverage of specific instances, but create a ticket for it, having it all under control The opposite (e.g. 3 months x n developers' work at 0% coverage) very likely has no way back

kwladyka 2019-05-09T19:07:36.085Z

For example if we want to fail all invoices which date is not in the current month

kwladyka 2019-05-09T19:09:09.086Z

Personally I found myself not able to fully test things which depend on third party systems. Just because there is no way to query this system without consequence and not able to make safe clone of it.

kwladyka 2019-05-09T19:09:15.086200Z

So on the end you never know

kwladyka 2019-05-09T19:09:55.087Z

And never trust documentation of third party system,. If they write in doc they return X it means they only write it in the doc, but system can return in corner cases Y

kwladyka 2019-05-09T19:10:06.087300Z

so true tests are on production 🙂

kwladyka 2019-05-09T19:23:03.090400Z

From my observation there is also another important topic which everybody miss. Psychology! We have different personalities. There are people who are good for making something new, but weak to finish the job to the end including optimisation for things like tests. On the other hand have people who do very optimised things and done the job, but if there is something what don’t exist already and they have to start something new there are much slower, because care about too much details. There are also different personalities like people who deliver weak code on deadline, but they care about time. And more…

kwladyka 2019-05-09T19:23:29.090900Z

I think this psychology topic is very important and it is very important to understand personalities in your team

kwladyka 2019-05-09T19:23:47.091200Z

Right people on right place

kwladyka 2019-05-09T19:24:15.091800Z

If you put wrong guy to the job he will fail not only because of experience, but also about his personality

kwladyka 2019-05-09T19:25:03.092300Z

team need to have mix of experience and personalities, but it is hard to achieve

kwladyka 2019-05-09T19:25:31.092800Z

people in team changing in time 😉

kwladyka 2019-05-09T19:26:01.093400Z

@d4hines ^ from another point of view, which we probably miss in discussion

2019-05-09T19:27:27.094700Z

That’s hard for me to grasp, seeing I’ve never done any management, but I’m sure you’re right @kwladyka, there must by psychological/social elements to it.