|
pr0zac posted:Yes. Please don't. Go is about as awful as nodejs. I hope it goes away as soon as possible.
|
#
¿
Sep 21, 2015 02:24
|
|
|
|
| # ¿ Apr 26, 2024 12:40 |
|
|
Totally. Rust is what Go should have been. It's doing fairly well considering how it doesn't have the backing of an enormous conglomerate. At least it has captured the imaginations of PL nerds.
|
|
#
¿
Sep 21, 2015 19:07
|
|
|
Doctor w-rw-rw- posted:I dunno, Java is the easiest answer. None of the good new languages are actually stable yet, and are missing some combination of good tooling, mature package management, and a good library ecosystem. I can forgive Java for a lot of sins because of that. But then again, college is lovely and instead of teaching students how to make the most of their IDEs, some of them teach javac with emacs with no libraries (or even Collections – yes I mean List and Map) allowed,, which is the stupidest crap ever. Scala is a kind of weird side effect of this. It became popular because it was an easy way to do 'more correct' programming without having to sacrifice much in terms of tooling or packages. Now that it has become pretty widely used, with its own ecosystem, it will forever be made slightly uglier than it could have been by its Java compatibility. I am glad we got what we did though, and I will happily take it as a manifestation of an enterprise functional programming language over that other Google abortion, Guava. I'll stop short of saying that uniformly all of the libraries/frameworks Google produces are garbage. Some universities are offering Haskell for programming language courses. That's nice of them.
|
|
#
¿
Sep 22, 2015 23:59
|
|
|
Really interesting report. Out of curiosity: If it doesn't give away too much information, what stage company is it? Are they doing well or have a lot of public exposure in their market? And is it in the Bay? I wonder if the devs there are just diehards who really believe in the mission or something.
|
|
#
¿
Sep 25, 2015 00:29
|
|
|
bartkusa posted:Even if they don't, I've heard it's common for growing companies to pay new hires more salary than early hires. It's easy; they can afford to now, they need more labor, and often enough the early hires never find out. Yeah, I get this feeling too. I imagine that situation is standard for any small company transitioning to bigger shoes.
|
|
#
¿
Sep 25, 2015 02:17
|
|
|
triple sulk posted:Python and Java are the only two truly employable languages of the four you listed. Interop aside, Java and Scala are basically not even the same language and 99% of Scala code is unreadable FP circle jerk garbage that still isn't as good as something like Haskell or F#. It has a horrid toolset, is slow as poo poo, and has a learning curve so bad that at one point they literally had "official" levels of Scala programmer skill (http://www.scala-lang.org/old/node/8610). Go has arguably been on a downward trend for a little while now because people finally realized that it's poorly designed. There are plenty of perfectly good Scala jobs out there. You just need to make sure that the organization isn't using it as a lovely Java++. Scala is much worse than Haskell or F# and every time I start a new Scala project I wish I was doing it in Haskell. But it's okay. You can live with it, especially if it is your job. You can make it entirely tolerable, you just need to be vigilant. Admittedly can get really annoying really quickly. Go is a joke and was designed because Google did not have faith that they were able to hire engineers who were smart enough to understand a real language.
|
|
#
¿
Oct 5, 2015 19:25
|
|
|
Pollyanna posted:I have a lot to say, but that doesn't mean I know what I'm talking about. Nobody likes uninformed opinions in any profession. But recognizing that you don't know what you are talking about is a first step, I guess?
|
|
#
¿
Oct 5, 2015 19:27
|
|
|
Urit posted:I'm not sure what to do next. I like doing what I've been doing, but IT operations is a dead end unless you're at a huge company, and even then it quickly peaks out and goes into management if you want to keep progressing career wise. I also enjoy doing software development-type stuff (that's what automation is after all - writing software to deploy servers/software) but I have no career background in software development and while I know a ton of practical stuff and can pick stuff up fast, I don't have enough of a background in dev that I get picked up when applying for jobs doing it. I'd rate myself as having about 2-3 years experience as a dev but without all the background in algorithms/data structures that a CS degree teaches. Give it a shot and start sending your resume out. Applying for a job is a low cost operation and there is no consequence for not getting it. All the while you gain good feedback. You can also start talking to recruiters, let them know where you are, and what you are looking for.
|
|
#
¿
Oct 5, 2015 21:27
|
|
|
Urit posted:I kind of already addressed that - I've tried applying for a few dev jobs and been screened out at the resume submission stage because I don't have prior software dev experience (that was the feedback) despite having "here's a project I did where I wrote code in the language you want" type statements on my resume. Maybe I will have to interact with recruiters. Sorry -- completely missed that part, I shouldn't have skimmed. Talk to recruiters. This isn't an overnight fix and it's hard to directly quantify the value but having some projects on Github is a really good idea. When I screen candidates I am overjoyed if they link to their Github, and I always check out their projects.
|
|
#
¿
Oct 6, 2015 02:17
|
|
|
It's not like I'm old as dirt, but at a certain point software development as an individual contributor gets less interesting, even as languages and technologies evolve. The more time you spend in your career, the more you will want to tackle larger and more complex projects. You will want to spend less time writing code or booting up servers because firstly -- you've done it a million times before and it gets boring, but more importantly, you will be occupied thinking about a bigger picture and you will need to delegate. There's only so much one engineer can do by themselves. Besides, companies don't want to hand out high salaries to people who spend their careers only working on small parts, unless it's highly specialized and highly critical. You will need to think about how your grand vision can be split up into parts, how it will fit together, what will happen to the whole project timeline when something is not built correctly or lagging behind schedule. Delegating is itself work, it's management. You can buffer yourself from a lot of management with a project manager and scrum master and engineering manager, but you will still need to work with them. You will need to work with the sysops or cloudops guys, the security team if compliance is at stake, product people and possibly sit in on business development meetings. You might retain your technical soul and focus throughout this and always be the principal engineer for the project, but you will need to learn how to manage. You can remain an individual contributor for life, and be extremely skilled and rewarded, but you will eventually reach a peak in your value to the company. You are limited in your capacity to build as an individual. There are lots of kids out there who write good enough code and who are willing to sacrifice more of their free time and eat more stimulants than you. There are fewer people who have good systems development and project management experience. Besides, code is fun for a while. But big systems are funner. sink fucked around with this message at 21:35 on Oct 15, 2015 |
|
#
¿
Oct 15, 2015 21:29
|
|
|
Che Delilas posted:You're making this blanket statement and applying it to all developers and it's simply not true for all of us. I am working with people right now for whom it's not. I made a lot of statements while hand waving wildly. Which one are you speaking to?
|
|
#
¿
Oct 15, 2015 22:30
|
|
|
JawnV6 posted:Principal engineers aren't management and aren't individual contributors. Your whole post is hyper-focused on the label "individual contributor" and ignores the gap between that and management that parallel technical growth tracks generally focus on. You're unable to formulate a definition of "leadership" that is distinct from management. That's totally valid. Yeah, I was speaking to ICs in particular but only. There is a lot of leadership space between management and technical IC, but I think a lot of (medium sized) organizations have a tough time defining or making practical use of that leadership role. I'd like to see more of it! And a lot of what I am describing isn't necessary people management. As a principal or fellow or whatever, you just plain need to know how projects work, so your high level contributions can be materialized.
|
|
#
¿
Oct 15, 2015 23:41
|
|
|
I think his point is that a a purely technical position is an illusion if you want to get anything done.
|
|
#
¿
Oct 16, 2015 03:42
|
|
|
It sounds like this is legitimately affecting your work. It seems to me the professional thing to do is to ask your manager first if everything is okay with your coworker, just in case that coworker has a special arrangement with the organization, for whatever reason. Don't throw your coworker under the bus, don't say that the situation is compromising deliver dates, just ask. If your manager doesn't suck, and they are paying attention to anything at all, this is more than enough to signal to them that they need to take some sort of action. If your manager says nothing or does nothing then they are lovely, but just ask your coworker if everything is okay the next time you see him. It's a pretty casual and normal thing to do. If he wants to dodge that's fine, just ask if you can take on some more responsibility so it's not a big deal when he doesn't show up.
|
|
#
¿
Oct 23, 2015 04:02
|
|
|
asur posted:Asking your manager about a coworker's personal life is not professional and talking to the manager at all is potentially throwing them under the bus, though that shouldn't matter all that much. If you have a good personal relationship with the person, I would just ask. If you don't or want to approach it professionally, then determine how their behavior is negatively impacting your work, what they could do to lessen the impact, and then approach them or the manager with that information. In this case, the issue seems to be not so much that the coworker is absent, but that they are not communicating when they will be absent so ask them to update their calender or whatever method the company uses to communicate when people will be available. I never suggested asking a manager about a coworker's personal life. That's nonsense. I suggested asking if everything is okay. That's it. Or don't go to the manager, go to the guy first. It doesn't really matter. vonnegutt and Doctor w-rw-rw- and everyone else who is acting casual as gently caress about a dead simple boring routine happening at the office is correct. There's a million ways to do this while remaining totally professional and not looking like a total goon.
|
|
#
¿
Oct 23, 2015 19:08
|
|
|
You guys work in weird places if your manager doesn't notice you only showing up to work three out of five days a week.
|
|
#
¿
Oct 26, 2015 00:19
|
|
|
Someone care to give a primer on the difference and the reasons why companies choose one over the other? The option guide above by mrmcd is excellent.
|
|
#
¿
Oct 27, 2015 01:49
|
|
|
Most of the places I've worked (SF and NYC) are very liberal with how much time you spend in the office and have very kind work from home policies. Smart managers know that if employees are engaged and aren't stressing out about picking kids up from daycare, making sure the plumber arrives before 9 or after 5, dealing with a 90 minute commute or whatever, then they'll be more productive during the time they are supposed to be working, and will often end up doing random things like answering emails or questions on Slack outside of normal work hours just because -- even if it is not expected.
|
|
#
¿
Feb 25, 2016 08:28
|
|
|
Urit posted:Serious question: Assuming I want to stay out of CRUD/Webapp hellholes, what's a well-used, well-regarded language to learn, assuming I have a fairly decent background in programming and already "know" C#, Python and 2 C-like hipster languages (rust and go)? I kind of want to learn JS just so I know it, but dynamic languages make me want to In order of arcana: Much enterprise systems programming is done in Scala, and the types can get mostly as crazy as you reasonably want until all of your coworkers loving hate you. It's especially nice because you can training wheels it by treating it like Java++. I am seeing more Haskell jobs being posted, and while it has its arguably strong negatives, many languages look to this for inspiration. It also does some things that Scala can't or won't. And OCaml if you want to work at Jane Street, Bloomberg, or Facebook. Idris if you want to a strict version of Haskell that allows you to formally verify a program that nobody in the world would ever hire you to write.
|
|
#
¿
May 19, 2016 00:25
|
|
because I can't tell how crappy my code is until I try to execute it, and where are my loving types?
|
necrobobsledder posted:Haskell is what's powering a lot of interesting projects under the hood though and I think interest in it is monotonically increasing as the bar for systems programming and correctness grows across companies that are hitting severe limitations with the "worse is better" attitude that's brought innovation in enterprise software culture to a standstill. I'm working more with NixOS and NixOps after years doing configuration management in the Ruby ecosystem and the cultural change appeals to the full-blown raging neckbeard part of me that's been in the witness protection program for about a decade. A lot of this would be tougher to write or reason about with something like Ruby or Python (evidence: Saltstack, Puppet, Chef, Ansible are all super duper side effects godzilla monsters in design intent - this is not the intent of NixOS at all). How does NixOS/NixOps compare to stuff like CoreOS? Or are they orthogonal despite the similar names? I've never used either. It's a bit of a new world for me, but I've been doing a minor bit of configuration and provisioning work using Ansible, and it feels kind of clumsy. (e: words) sink fucked around with this message at 05:52 on May 19, 2016 |
|
#
¿
May 19, 2016 05:32
|
|
|
I work on an SOA in 'da Cloud.' In interviews I ask a little bit about threading, mostly about resource starvation. If you look like you have that kinda exposure I will ask about actors or greenlets. I am more interested in talking about consistency, availability, queueing and idempotency though, just because of the relevance to what we spend most of our time thinking about on the job. Edit: To clarify, I ask more about distributed concurrency than threading in a single vm or service. Both are extremely important. sink fucked around with this message at 07:09 on Aug 11, 2016 |
|
#
¿
Aug 11, 2016 06:34
|
|
|
Go to a new place. 5 years is enough tenancy to demonstrate to future employers that you can be loyal. Now is a great time to get the experience of a new workplace culture, a new way of doing software and systems engineering, and a new way of doing product management and business operations. Maybe not all of those facets will be steps forward at your new place, or even all that different, but it's good to widen your range of experience. There's much more to to gain from joining a new company than a title change and a salary bump and a new project.
|
|
#
¿
Sep 23, 2016 01:41
|
|
|
necrobobsledder posted:Github still uses Rails at this point last I saw. Then again, I've heard that things suck at Github now that they took on a bazillion dollars in VC finally. Airbnb is also committed to Ruby. I've heard unsubstantiated rumors from people who have interviewed at Airbnb that they want to do to Ruby what Facebook did to PHP. I think Uber is Python, largely. Youtube is/was Python. Java still wins, sort of. Any large successful business is going to have multiple teams working on specialized aspects of the business or internal services, and that means enterprise middleware software goons writing Java. The hip places will have moved onto Scala for some things. And the hip teams will want someone with either Scala experience or Java and one bonus language, like either Ruby or Python or Clojure or whatever. In my experience, language will be somewhat secondary if you can talk about service oriented architectures and multiple types of databases when you are interviewing at a company selling a cloud computing or SaaSy type product.
|
|
#
¿
Sep 28, 2016 04:53
|
|
|
oliveoil posted:I want to learn to make the cool high-performance, large-scale systems that you think of when you think about the major tech companies like Google, Facebook, Amazon, Microsoft, etc. Currently, I do small-scale python stuff. If want the best bang for the time I invest, what should I do to learn? Grab a classic book on C or C++ or a new one on Go or Rust or what? Or maybe since I have a low level of familiarity with Java already, I should focus on that? Scala, Java, and (unfortunately) Go. Folks try to avoid C/C++ unless, as mentioned, it's important for ridiculous real time performance (finance, adtech, voice/video). Even then, a lot of orchestration is done on the JVM before and after the performance-critical parts. Microsoft is in .NET, naturally. You're going to find a standard set of languages, but what's more important is how the higher level components fit together in a distributed system that expects to be able to handle large fluctuations in traffic and a certain tolerance for failure. Learn about how different queueing technologies work. Kafka is very different from RabbitMQ, is very different from Amazon SQS. Containers, and container orchestration will likely be useful to you. Learning when you can have different consistency levels for your data is useful. And what databases can provide those guarantees. What are good ways to select sharding keys for different applications? Being able to answer what goes into a high-availability, zero downtime distributed system is important. What can you horizontally scale easily? What is harder to horizontally scale? What are good ways to partition inflight and postflight systems, the latter for data warehousing and offline processing?
|
|
#
¿
Dec 13, 2016 01:40
|
|
|
To be fair, minato was making a point that there is room for it if that is what you want to do. As they said, the field is broad. And every application is different at scale. I don't work at Google or Facebook scale, but gc pauses used to gently caress my life. So when I can figure out how to half my allocations in a service, I get excited. For other services, even if the performance is abysmal, I know that throwing more instances at it for now is far far cheaper than dedicating an engineer to rewrite or performance tune. Especially if it is already in production and its failure modes are well known. sink fucked around with this message at 08:22 on Dec 13, 2016 |
|
#
¿
Dec 13, 2016 08:19
|
|
|
I'm lagging in this thread, but I remember a few pages back folks were talking about embedded systems. Embedded and machine level stuff isn't my cup of tea, but a formal verification position showed up on a Haskell mailing list, along with some other really cool operating systems positions at this company. Thought I would mention it here as an example of what's possible in the field: http://kernkonzept.com/jobs.html
|
|
#
¿
May 16, 2017 20:06
|
|
|
Most folks in the corporate functional world recognize that it's rare to see 8 years of OCaml/Haskell/ML experience, so they're happy if you've got an open mind, tolerance for screaming arguments with a compiler and maybe read a couple of chapters of SICP or Learn You a Haskell. In addition to Spark / Scala, that's the way Java is going anyway slowly. Java8 added Optional with flatMap, lambdas, etc. I've even seen people writing code that goes into services built with that horrible Dropwizard framework which uses Eithers instead of exceptions for error conditions.
|
|
#
¿
May 16, 2017 22:58
|
|
|
Pollyanna posted:Happy new year! What’re your career resolutions this year? Mine is to be better about getting work done right the first time, to ask better questions, and to have more confidence. Hire 6 engineers. Open a new office in the SF Bay Area.
|
|
#
¿
Jan 1, 2018 22:07
|
|
|
|
| # ¿ Apr 26, 2024 12:40 |
|
|
minato posted:Impostor syndrome is definitely a big enough problem at the BigTechCos that they have to warn you about it in onboarding. But at least in my experience they did very little to tell you how to combat it. I agree. And to add to that: For better or worse, tech can be very hero-oriented. But it's good to know that the reality is: at BigTechCo, $AmazingThing was probably a large project involving multiple teams and roles, and more than a few non-tech folks. It was likely an iterative improvement on someone else's research or product. And it might have taken a long time with a couple of false starts and dead ends. It was hard for the celebrities, so it's okay if it's hard for you too.
|
|
#
¿
Jan 1, 2018 22:28
|
|