Nothing here yet.
Nothing here yet.
Hiring people based on their "identity" to fill quotas is plain stupid. Have a diverse work force by all means, but let it arise naturally. Don't try to fill quotas. I'm a visible minority and I would absolutely hate to discover that I'm hired just to fill a minority quota.
What good will it do to try to pressure that company to change their ad? All that will happen is they will stop telling the truth and pretend (on paper) to be welcoming to both genders, but in reality they will still act in a way to prefer men because they have specific reasons listed on their ad. So, if you want to comment, go ahead. If you want to change their mind, don't waste your time.
know that this is a problem of discipline It's not a problem. Your mind wants you to know a lot about many things because knowing more about more things is a good thing. I think this problem also comes from the fact that I don't have a goal for myself. Once you have a very concrete goal your mind will naturally guide you to focus on what it thinks is the best path to get there. Think of it this way: Without a goal, your mind wants to learn as much as possible because it doesn't know what will come in handy in the future. With a specific goal, your mind can focus on things that will help you achieve that goal. Sometimes, you have to put yourself under real stress to achieve your goal. For example, if you are living comfortably (in your parent's home, for example) your mind will think there's no reason to focus too much on working a job, because you will not starve. If you force yourself to live on your own, your mind will see that if you don't work, you will become homeless, so it will help you focus on specific things to make you good at your job. Basically, stop fighting your instincts. Understand why your psychology is helping you, and setup your environment accordingly.
Ramakrishna Joshi Think of it in terms of having options and being fragile. If you specialize into a very narrow field, your career path is very fragile, because guess what, 6 years from now, whatever library/language/framework you spent so much time on is not going to be popular anymore. Also, you can't be among the top 1% of android developers if you're not also among the top 10% of programmers.
If the industry had a consensus about what constitutes a well designed language, there would be far fewer languages than what we have now. Every new language coming into existence is being designed by people who are not satisfied with any of the existing options, and decided to make their own. The designers of Go-lang think it's well designed, but many others disagree. Some disagree because they think lacking generics is bad. Others disagree because they think a GC is slow and communicating via channels is slow. The designers or Rust think it's well designed because safety is of the utmost importance. Others disagree because they think Rust has high friction. Some language designers want to prioritize "enabling good developers to get work done", while others prioritize "preventing average/mediocre programmers from making errors". Some people think a well designed language has compile time type checking, others think dynamic typing is better. Now, when it comes to my personal opinions, here they are: The official compiler should be really fast. It should be able to compile a large code base in under 1 second. It should be able to cross-compile to other platforms with minimum effort. Compile time type checking is absolutely essential. It should be able to effortlessly compile the project to a single statically-linked native binary executable. It should enable a mode of programming where the programmer has control over memory (writing custom allocators, running without a GC, etc), while still providing ways to help the programmer to just write code without having to worry about these things when needed (e.g. optional GC or ARC).
Some startup founders hire people based on their exploitability. You will likely be expected to put it a lot of hours, but won't get much in the way of financial reward. If - after you have worked there for a while - the founders start smelling like psychopaths, don't hesitate to let go.
I would say it's "Information hiding" and "building everything as layers of abstractions". Abstractions are good, but too many abstraction layers are often a disaster. Sometimes you want certain implementation details to be hidden or ignored, but these cases are rare, and the most common case is that you want the implementation to be a "white box" that you can peek into and change.
I would say it's a really bad idea to work with 8 juniors. Most juniors have a lot of wrong ideas about how to build applications, and if there's no senior around to weed out the bad ideas, you will likely not learn them on your own. Worse still, some of the juniors can be really enthusiastic about their bad ideas and try to spread them around, so now you could have two problems: the bad ideas your originally had, and the bad ideas you learned from your colleagues.
When you come back to it 3 months later, how easily can you remember what it does? How easily can you change it to add a new feature? If there's a bug, how easy (or difficult) is it to navigate the code, figure out what's causing the bug, and fixing it?