I like to say to juniors that they need to be loudly active. If you do a good thing, ask a random question about it somewhere your manager can see, especially if he didn’t explicitly instruct you to do the thing.
They’re not mind readers, and most of them are pleasantly surprised when you do things that make them look good.
I'm a little bit astonished by the comments mentioning regex.
I used Gerkins at work and there was no regex at all.
Once you write it, you can use the sentence for building other tests if you design it for being flexible and variable, i.e. design well enough your code.
Given I'm connected as ___ with password ___.
When I click on the element __.
Then the element ___ is present.
Then the element ___ is present.
[...]
For critical use case, it was enough. For more that's a bad idea: it take way too much maintenance cost.
Unfortunately, the way ads work, the people who pay to avoid ads are inevitably the ones worth advertising to. The Nash equilibrium is that every user sees ads.
That sounds off to me. I would think that the people who pay to avoid ads are very likely to jump to ad blockers if the ad-free subscription ceases to exist. Not to mention that they’re going to be very unlikely to convert on advertising.
The paid service would of course have to offer something else other than “no ads” if they started showing ads in it
The type of people who have already indicated that they have disposable income, and are willing to pay for a service, are more attractive to advertisers than people who are known to have opted for a worse experience for free
If the LTV of a "good" user (e.g. user who buys things from ads) is X, you price the non-ad tier at X + Y. Y is the premium you pay for not wanting to see ads.
So you're right, but also wrong, in that you can extract EVEN MORE money from the user you were talking about through a non-ad tier.
Companies (Meta, Google, etc) get better at advertising -> LTV goes up -> non-ad tier goes up
My experience based on web oriented technology with overcomplicated systems choices :
- End to end testing is good for critical path (customer can create an account ? Otherwise he will leave for another company = very bad). It cost a lot to maintain thus, must be very important requirement. Page pattern with selenium is good.
- Hight level Integration testing (real component, no mocking) is great : tons of error come from the integration of the many components/teams (BDD, ETL, external API/lib, [...]). When tested from your API end point, you have a great ROI and good security harness to avoid regression. By the past we used postman but there is better alternative now.
- unit testing : good when you have control of the solution. As software integration team, working on very legacy solutions, core logic doesn't belong to us. Unit test have not been helpful in our case when using mock (too much maintaining cost)
Today, we encountered a very critical bug that would be missed with unit testing and integration testing, which changed our whole approach towards how we view testing. It was a simple scrollbar not being able to scroll 90% times only worked 10% if a user did very specific thing. Overall chance of getting noticed in beta test would have been 2% but as a startup this could have been our end, because unless user added more than 5 files one could not test the scenario, which is the avg. for any trial user. But a real user would have noticed this and would have left for another company. When we started we hadn't hoped this would be an issue but here we are.
It depends on what are you vision of the "programming skills" and how you define a "better programmer". There is so much area of expertise to master them all..
You seems to have a certain inclinaison for scientific programming. I suppose it's in this area that you want to have better programming skill.
The book that I heard a lot about is the following one (it's on my shelf) :
- The Art of Computer Programming, Volumes 1-4, by Donald E. Knuth
Some books are more generals and provide insightfull tips that I found quite helpfull :
- 97 things every programmer should know, by a lots of people
- The pragmatics programmer, by Andy Hunt and Dave Thomas
- Clean code, by Robert C. Martin
If you want improve you skill about a particular programm language, the best is learn every kog and what happend under the hood of you language. Books, Video, any things that will help in that direction, it depends of your choice . Usually it takes time to improve.
There is many type of language and big difference inside those type : Scripting languages (python,bash,js...), compiled languages (c,c++,java,c#,...),...
If you know different tools you are more likely to be able to use the right tools for the right jobs.
But the real advise is to be doing some real stuff : face real world problem
Being far above good isn't enough either. Being highly productive and effective result in work done faster.. and more work given !
Better to use your skill at your service rather seek/hope for promote.