My commute has been ~30 minutes for the last nine years; for most of that it was driving ~25 miles outside the city, now it's a 20 minute bus ride and 10 minutes walking. I rather enjoyed the drive, but it helped that there wasn't traffic (I imagine 30 minutes of open road is much more enjoyable than 30 minutes of traffic).

Our build scripts run unit tests so if they fail they better get fixed.

And you can't even make a front end pr if they fail.

Yeah we don't have automated deploy but the tests run against prs and people can't merge until they pass. The failures are intermittent so basically 1 in 5 tests fail for some reason that doesn't actually indicate a problem with the correctness of the code.

Still trying to learn basics and not generally making too many modification since learning and re-creating things constantly , in order to learn.

However more in general level on personal freedom / vs efficiency, I would look first how big problem it is really is. One could have spent even 20 days troubleshooting silly customizing issues, but depends how many devs there are, during how many years it all happened etc. hence difficult to make judgement call when it is too much work to allow certain freedom. Possibly the modifications are improving the efficiency in other areas, keeping devs happy etc.

too early without fixes. If I was able to have fee reign, I can fix most of it.

Let's not kid ourselves.... 90% of programming is basic tasks. This doesn't mean I don't write tests at all; I just think that they are needed much less than people claim.

Unit testing.

If you were in charge of the project with several devs ,what would be your take on testing and QA. Would there be level required on unit testing or just how each of the devs feel or external automated testing on some important values / functionalities etc. or once things been integrated.

This considering that some stakeholders would be asking how things are going and to show some proof. What would be the function of QA?

Just interested of the alternatives.

Mind that I'm mainly a lone wolf. I'm working with a team now, and it's strange to me. As a lone dev, I see it as my job to write good code and to write proper tests.

I think the degree of testing really depends on the quality of the team and the stability of the code base. I'm not entirely sure about automation as a standard operating procedure, as in some cases, it would be easier to simply rewrite the code. I think that, counterintuitively, weak programmers don't benefit from testing as much as middle or strong programmers.

I guess to try an answer, I would expect most code testing to be done by the developers, and most manual testing for IU and functionally to be done by QA. It's one thing to pass a bug, it's a whole nother thing to pitch everything over a wall and expect some one else or a robot to figure it out for you.

I'll double post since I'm on my phone. Someone once told me that a good QA is a breaker, while a programmer is a builder. The QA is diametrically opposite to a programmer's intuition, and that relationship is very powerful.

That's the point - it's not like writing a complicated math proof, but taking care of a long list of edge cases. And performing such basic tasks reliably is surprisingly difficult for humans, especially at scale necessary for today's large systems. Tests exist to catch stupid mistakes, not fundamental design errors.

This depends on your scale, reliability requirements and frequency of changes. The larger your system and the greater your reliability requirements and the more frequently you deploy, the more important it is that you have a reliable automated test suite that covers large portions of the system. It's hard to talk about the importance of automated tests in the abstract without understanding the nature of the system and the business requirements. I will say that I've rarely seen systems that had adequate levels of test coverage.

I literally had a hotshot "architect" at one of my first jobs, after us reporting to him that his code didn't work, tell us: "I looked at the code. It works." Well did you run it? No.

Narrator: "The code did not work."

Needless to say - "I looked at the code. It works." - was a running joke on our team for years.

Perfect example of why I love programming. You can only bull**** so far before your **** has to work.

In my experience so far, the mass of bugs really comes from a) over engineering and b) writing Language X in Language Y.

I hate the idea of joining the side that seeks a Language X guru, but I'm starting to understand the perspective.

I do backend development so there are no need for front end tests. So in my opinion high coverage should be achievable. If this was iOS app or something front end heavy, then yea I see very little value in tests.

I'm not sure what you're trying to say but if you have, say, a 100-person engineering organization, your engineers will do lots of things, including above, that will produce lots of bugs. Unless they are caught and reported back. The only question is whether they are caught during development, testing or in production. "Let's write bug-free code by doing all the right things" is not a methodology.

That's like doubling down on the standard "does it work?" "it compiles" conversation.

Obviously I'm not talking about 100-person orgs. I don't know and don't want to know what that is like. I'm sure finding gurus doesn't scale, so it sounds logical to me that you would need many more stop-gaps in place.

A 100-person organization is a fairly small company and large-scale software engineering is what matters and is hard - the majority of useful software (weighted by usefulness) are large systems and the majority of well-paid software developers work on small parts of large systems. Writing high-quality, low-defect, self-contained small programs that are measured in thousands of lines of code is mostly a solved problem. Lots of things work very well at that scale. This is not what we're worried about.

The problem is also not that small companies with small code bases can find gurus to work on and large companies can't - from what I can tell, most actual gurus work at large tech companies. The problem is that the quality bar that is acceptable when you're dealing with small programs is absolutely unacceptable when you're dealing with large systems. As a very simplistic example, let's say you're a great individual programmer that ships a critical bug 0.1% of the time. Each change you ship basically has 99.9% chances of not having a critical bug. This is pretty good if you own a small web application with a few clients. If there are a thousand such programmers working independently to ship features in the same release, 0.999 ^ 1000 = 0.367 - you will get a critical bug 63% of the time. This is completely unacceptable.

I think that scoots back to what I said about testing being less useful for weak devs. My observation / experience is far worse than 0.01%. At some point, the tests are effectively rewriting the program,so the trade off gets closer to why bother?

If you let weak devs write their tests you'll *probably* get weak tests too, unless the reason they're a weak dev is that they were born to QA instead (see break vs fix above, which I 100% agree with, an actual good QA person tries all kinds of devilish things to break your stuff)

In an ideal world I think there would be a department or group that mostly writes tests. Big companies have these, I have several friends who started by writing and running tests suites for IBM AIX. They might spend weeks or months trying to break some video driver or something.

A lot of the pushback for testing comes from the fact that it is really common to want to make a simple 1 line change - it'll take 5 minutes max. Writing a good test for that change might take 2 hours. It's tempting to think that this means you'll spend 95% of your time writing tests, but it's also usually the case that if you add a feature and it takes 2 hours, or 4 hours, or 8 hours, writing tests will probably only be 2 hours. That is, testing difficulty often does not really scale with coding difficulty.

I'm also saying that an external tester loses value when you are dealing with weak devs. You need a code reviewer or someone to go through and rewrite everything.

Yes and no. If the tests are good and the code passes tests, then it's at least functional. If/when it gets rewritten by someone better, the tests are an invaluable time saver to the rewriter.

I actually think people put too high of an emphasis on code quality. If it produces the right answer and it's fast enough, well, that's a pretty good start. A huge percentage of code is thrown away in a year or two, let's not pretend we're building the Taj Mahal.

I think code quality is very important. I don't mean that you have to be writing e=mc^2, but you should be following the languages semantics. That makes it easier for the next person, and following semantics makes the code much more readable.

In the current contract, we are using Python. This is great and all, but nearly every single loop and string manipulation involves an index or counter. This is incredibly non-pythonic, and only made worse because Python's style of indexes and results of many functions is counter-intuitive. This not only makes things hard on the person writing the code, but makes things very difficult on the person who has to both write tests and clean up the code. Good code is both functional and has an obvious intent.

A working definition of code quality would be a good start...

Bad: 6 hours writing a 25 line function

Good: copy / paste a 3 line solution from StackOverflow.

Nah that's cheating. If it's too simple then clearly you put in little effort and deserve little credit.

/everyone at my work

Better: write a multi-headed hydra 500-line function that attempts to anticipate every possible need the function might have for the next 5 years. Then create a wiki page for it.

Best: pay a vendor $5M to supply an all-in-one solution that does the work of 100s of other similar functions you can think of. Except for your original function. But they assure you it can be customized to handle that.