Ask HN: What is development like at your company? | Hacker News Reader

Ask HN: What is development like at your company?

9 pointsglockie9 comments

This is my first "serious" software job, so I'd like hear what your experiences have been in the industry.

What is your tech-stack like? What languages/frameworks/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/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?

I'm asking because I work at a very "well established” business software company and the reputation far surpasses the reality in my opinion.

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 "business data" is passed around as raw JSON objects who's structure you can'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'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'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.

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 :)

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.

To the OP, if you're one that "cares" about the job and want to be one of the "25% that gets asked" then your current position does not sound like a good fit.

One plus side: based on your experience in this company, you probably know more about what to look for and ask about in future interviews.

You might want to look at joining a smaller company. That probably means less job security but a better engineering environment. (then again I'm biased towards smaller companies).

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...

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!

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).

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.

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.

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).

Reply on news.ycombinator.com