3
points
AdityaSanthosh
Joined 30 karma
pssanthoshaditya@gmail.com
- AdityaSanthoshHi, I am one of those code monkey you mentioned. I never took affinity to computer science/math, but I love building real world products with software. I built some really hard and interesting products. Basically, I love playing with tools and building tools from programming paradigms I know. Right now, I am struggling with all the interviews that have these leetcode problems. What sort of career in IT do you think would be best fit for me?
- How are you determing if a ad is harmful
- Hi, seems like an interesting course. I haven't studied compilers in my undergrad( I'm an electronics student) but I have been working as a programmer who studied c and bit of low level languages. Is there any prerequisite compiler knowledge required for this course?
- 1 point
- Just curious, why do you want that to be version controlled?
- I will propose automated tests to my manager. Writing tests for shared code is a great idea. But I feel I should concentrate on integration tests as well (like flows spanning multiple lambdas)
- On an unrelated Note, I admit I hated the idea of setting up processes because I enjoyed the freedom given to me by my manager to make architectural and code decisions on my own and move fast rather than following rigid practices. I am not sure if that mindset is good.
- I created a staging setup, the CI/CD pipeline already, I pitched to my Engineering manager to get me a QA. I will push harder from now to smoothen the deployments.
- > I take a very large example of real-world data (say 95th percentile of what is actually used in the wild) and develop with that as my backing data. If operations are slow enough for me to be annoyed in development, clearly they will be too slow for the (many more) people who have to work with the project once complete.
Interesting point. Will try to incorporate that.
> Does making a change in one flow tend to adversely affect seemingly unrelated others?
It doesn't happen that much, but because there is a lot of intersection between those flows, they are kind of interlinked(to reduce code duplication). But point noted, I will try to see if they can be separated.
> Lock the `main` branch, only allow commits to it from PR's. Review your own PR's.
Done.
> There are no bad queries, only insufficient validation and/or timeouts.
Validations are huge issue. When you have hundreds of variables and one of them throws DivisionByZero error or invalid data type, those are hard to catch
Loved these suggestions especially the first one. any more ideas?
- 2 points
- In my observation, DE interviews even if they are leet code based have relatively easy compared to that of SDE roles. And it is not like I hate DE, i like it too.
- The intersection of no of companies that do not ask leetcode, which pay reasonably good is very low and it is really hard to find them
- 15 points
- 14 points
- 1. No ads 2. Punishing bad behaviour over perma-banning profiles. 3. Unbiased moderation 4. No adult content 5. No alt or bot accounts 6. Some puzzles/activities. Engaging content without sensational news 7. Should have healthy mixture of text content(more) and short videos
- 3 points
- Nonsense. There's a reason why Bangalore, India is the hotbed of startups, innovation , manufacturing in India because Bangalore's weather is so cool and moderate throughout the year unlike coastal cities. Climate change is a major factor in economic growth
- Indeed. I'm learning oop in python and was interested seeing the title
- So cool. I love rust and my day job is in Python.
But I have a question. I'm a junior dev(gimme some leeway here).
I don't really understand how important these design patterns are because in the programs I write, I usually write the classes and call them in runtime myself. I think usually we write the servers and client ourselves.
Let's take the different client types example. You are making an assumption that users can call close on a closed client. Is it so hard to just follow the sequence
` client = Client()
client.connect()
client.authenticate()
client.send_message()
client.close() `
Aren't they overengineering? Perhaps I have not worked in a large code bases to understand the problems TypeState Pattern or more generally these design patterns solves.
I understand that these patterns are elegant and make the future modifications or enhancements easier but I have never seen the tangible value enough in real life