
Ask HN: What is development like at your company? - glockie
This is my first &quot;serious&quot; software job, so I&#x27;d like hear what your experiences have been in the industry.<p>What is your tech-stack like? What languages&#x2F;frameworks&#x2F;tools do you use, and are they working for you, and why?
What is the “common practice” like at your company? Do people write and&#x2F;or design code well? Do you test and document code?
What is the culture like? Do people communicate effectively? Are there deadlines? Is management reasonable?<p>I&#x27;m asking because I work at a very &quot;well established” business software company and the reputation far surpasses the reality in my opinion.<p>Firstly, the software blows... super hard. Most of your product is written in JavaScript (front-end and back-end). Of course, this is a complete nightmare as we have over 500 active developers on the project. Not to mention the fact that at most 5% of the code is commented or documented in any way whatsoever. This makes maintenance, code-reading, refactoring, and testing almost impossible. Broken hacks are fixed with more broken hacks, and most of our &quot;business data&quot; is passed around as raw JSON objects who&#x27;s structure you can&#x27;t possibly know until you evaluate the objects at runtime. Perhaps the worst part is that very little of this code is tested. In fact, large areas of our project are hovering around 50-60% code coverage, and these are areas that are responsible for handling our customer&#x27;s financial data. The part that irks me the most is that most of our additions and new features are merged without any unit or integration tests whatsoever. Instead, we relegate all our interns to do manual testing on our product on a weekly basis, so when bugs make it into production it&#x27;s their fault for not finding them, never mind that new features are often not even manually tested by the people who developed them. Yes, you heard that right, senior developers write features without any unit tests, throw up some manual test plans, and then hand them over to the interns to test.
======
telebone_man
Considering my whole career, I'd say you should probably get used to it and
evolve!

I don't mean to sound defeated. Sometimes projects are done 'properly'.
Documentation... Good code over 'code that just works'... etc. But sometimes
the business need to just get something released can outweigh that.

Picture this - the business has an opportunity that will generate £x in
revenue. This revenue will ensure your job. It'll contribute to the coffee you
get to drink. And other benefits you might take for granted. The catch is, the
code to fulfil this opportunity needs to be written in 3 months when you know
that it should take 9.

This situation just requires a different way of working. And a different set
of skills. Such as understanding the requirements to a tee so that you can
produce the absolute minimum. Delegating where possible (such as letting
others do the testing - if they're doing that badly, that's not your problem).
I'd say over time I've gotten better at reading code that isn't commented.
(hint:learn how to use a debugger for your given language). I've also gotten
better at writing short snappy docs.

To answer your queastions directly, again across my career... \- Tech stack is
normally 50/50 modern and legacy. \- Both the modern and legacy
languages/frameworks/tools fulfilled the end-user requirements set out in the
first place. \- Common practice is 50/50 people who care about their job and
those who just want the paycheck. \- 75% ask for advice on architecture from
the 25% that can do it well. \- Culture is what you make of it. If there's no
scene, create one. (just like punk music). \- People only communicate when
they need to \- Deadlines? Yes! They're normally not met though. See above! \-
Management reasonable? Subjective :)

~~~
scalesolved
I think you make some excellent points. I think the oft mental block engineers
stumble into is that management are often not clear in articulating that speed
for a certain project is more important than reliability or quality for
example.

There is a trend in our industry for each company to claim they fulfil
speed,quality,cost.

------
matt_the_bass
Wow! That sounds awful. I'm sorry that you found yourself there.

As someone in "management", i fully understand that business needs do not
always align with ideal engineering solutions. At my company we try to have
team discussions whenever we "solve it with a hack".

I fully admit, we don't score a perfect 12 on the Joel test [1] (and I don't
agree with all 12 points as always being the goal) but we do always strive to
make all code we touch "better" than before we touched it.

Your situation does not sound like a place where you will learn a lot (which
in my mind is one important goal of a first job).

Can you discuss your concers with your supervisor? Can you convince them to
clean as you go? What are the opinions of other, more senior programmers? Is
the moral bad?

[1] [https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/)

------
ix-hispana
I work at a small company. We have 6 javascript developers. All our web
projects are node, typescript, and the front end stuff the client wants us to
use (though we default to angular). We enforce types for communication with
node, so at least you know the structure of all the json going through the
network. On the node side we use loopback, which generates a nice site to call
the API from outside the project.

We write no tests whatsoever. This is a business decision.

There's a test team of 2 people whose job is to go through our crap (i.e., the
user stories) and write docs.

Management has to adapt to clients. Managers use the agile words, but the
client's budgeting procedure has to take precedence. Regarding estimations,
there's no analyst estimating features and tasks, the developers do it
themselves. Developers also talk directly to clients often and go on-site.

Since we're so small (about 30 in total), things are personal. We know
everyone personally and can make out who wrote a given piece of code. I think
communication must be easier with fewer people. I can't imagine having 500
people committing into my project!

~~~
gubsz
I always question the 'business decision' to not write tests. How did
management justify this point to the developers? Was there any push back?

I ask because our business team has a similar stance on developers writing
tests (i.e. it's not worth the effort).

~~~
jrowley
I think it comes down to the complexity/size of the project, the amount of
turn over in the team (with higher turn over you're using going to want more
tests and docs), and overall willingness to invest in the product health. Some
teams rather take on the technical debt in 1 project so they can move onto
other projects.

------
ajeet_dhaliwal
The complete lack of any automated testing whatsoever is not ideal but what's
nightmarish about JavaScript? It's my favorite language nowadays (modern JS)
and I've used C++, C#, Java, Python, Objective-C, Swift, Lua, and about 6 or 7
others over the 15 years since I graduated. JSON objects are easy to verify if
that's how your 'business data' is passed around.

------
djellybeans
Evaluating a company from head to toe can be very hard during the interview
process or even the first week of work, because you only see the tip of the
iceberg. I've been in many places where there is complacency to update the
tech stack, or fragmented communication (imagine working right next to another
programmer who has not heard anything about the project your manager gave you,
or someone stops coming to work and later the management casually tells you
they're fired).

I don't work right now (but currently looking) and I left the last job quickly
due to disagreement on terms, so I don't know if my answer to your question
would be very helpful to you.

I was hired as a telecommute contractor for a small web development agency
that just set up business about 2 months ago. They had three or four other
programmers also telecommute (I can't exactly remember, only really worked
with one during my short time there).

First, the good stuff- their stack and development setup is very sound for the
most part. Their work looked well managed on a technical level. Projects are
divided among other remote developers using Gitlab. All bugs and tasks are
tracked there. Most client projects use modern frameworks such as Laravel and
React. We are all encouraged to use their Vagrant dev environments with
virtual machines, so everyone's on the same pace. It's the most modern
approach I've experienced in web dev career (which doesn't say much, my other
employers were lagging behind).

Now for the bad- business billing practices that didn't quite sit right to me
as a contractor. Having worked for web agencies before, I'm familiar with
process of billing clients. Previously, I'm always the one making the time
estimates, if the manager expects them. However, they just threw me into a
project without much input and expected me to take its estimates (given by
their lead developer) and bill according to what he estimated. Also was
expected to be present online for 35 hours but not being able to bill for all
35. I filled out a W-9, identified as a sole proprietorship. I felt like I was
controlled more like an employee, one who the company isn't paying taxes for.
Plus, the business owner didn't even give me a work-to-hire agreement to sign.
He actually said "we don't do contractor agreements".

So all put together, it sounded like an attempt leverage me into a very bad
deal. That's how we broke it off, he accused me of being unprofessional
attitude and didn't take well to my "f* ck you, pay me" approach that
freelance contractors are known to defend themselves with. I never had to take
that stance before, as all other clients I've contracted for paid on a more
sensible hourly basis (and give actual contracts to sign).

