Oops I mistook it for "Project" management. For such a certification in Product management you could check out Coursera's Brand management course: https://www.coursera.org/learn/brand
Actually with Project management the case is a bit different. There is a central body called "Project management institute". They have a selected number of certification options that are recognized globally. You can defnitely attend free courses but only PMI can certify you to be certified Project Management Professional.
Start by gathering the best writing samples your team has completed. Identify the most appealing aspects of each document. Review the lists of positive responses for patterns. With enough documents and enough people participating, you’ll arrive at a consensus standard for quality writing: A set of models and specific language that describes exactly what your organization likes about them.
instant feedback is possible in Go as it compiles super fast. Also its much simpler to write cause its a small language and the concurrency primitives are so simple to understand and use. It has its problems but its a great choice here.
The most valid reason for using a language is simply because the team is comfortable with it.
> instant feedback is possible in Go as it compiles super fast
Heh, you should try a language that comes with a repl and allows you to evaluate code directly from your editor in any context and get the results back. Then you'll have experienced "instant feedback". Until then, I can agree that Golang compiles faster than other languages, but it's nowhere near instant. In some other languages, you don't really care how fast it compiles as you only do it for deployments anyways (like Clojure).
A REPL only gives you instant feedback on code that you type into the REPL. If you make some changes to three modules and you want to find out the effect of those changes then you need to...recompile the modules. Having a REPL doesn't help.
I don't find that a REPL really gives me anything that I don't get from tests in Go. The only difference in practice is that I type the code into a text editor rather than into a REPL prompt (which is actually a better experience). On top of that, it's usually good to have that kind of code saved somewhere rather than existing ephemerally in a REPL session.
Depends on how the language you use works. Golang is not made for repl usage so of course you don't really get the full power. Compare with something like Clojure where redefining a function in a repl, makes every function using that function also use the new definition. Start treating functions as just functions without any implicit state, and you can start to overwrite things in the program on the fly. Super valuable when debugging and otherwise also when creating code as you can much easier test ideas.
I don't know if it has a different word, but a repl for Clojure using a repl-workflow is very different from a repl for Golang with the normal "save -> compile -> run" workflow you have with Go.
For example, using a repl-workflow in Clojure doesn't mean you don't write code in your editor. I use vim + vim-fireplace to write my code, then highlight the parts I want to evaluate. So I get both in one. The repl is running in the background, and vim-fireplace communicates with it. Combine this with a SPA and I can have something like `(.alert js/window @username)`, highlight it and evaluate, then have an alert prompt in my browser window, which is next to my editor. Saves me a ton of time.
Yes, I've used Clojure and other Lisps before. The thing is, I don't want to overwrite function definitions in a REPL, because I then lose track of what code I'm actually running. It's much more effective just to make changes in a text editor and track your state using version control. In a language that compiles quickly, a REPL just adds an additional layer of complexity for no benefit. In a language that doesn't compile quickly, redefining functions on the fly in a REPL is a useful hack that lessens the pain somewhat.
>I use vim + vim-fireplace to write my code, then highlight the parts I want to evaluate. So I get both in one.
Sure, and with Go in VSCode, I just click 'run' above the test I just wrote. It isn't any more difficult.
> much more effective just to make changes in a text editor and track your state using version control
Statements like this makes it seem like while you probably have dabbled in Clojure and other lisps, you haven't used them substantially, as if you're using Clojure, you still make your changes in your favorite editor and code is still tracked in version control. It's not REPL _or_ code editor, it's code editor + repl backing.
Redefining functions on the fly is not a hack to lessen the pain, it's a defined workflow that makes you be able to work faster. If you're using it and it feels like something to lessen the pain, you're using it wrong.
> Sure, and with Go in VSCode, I just click 'run' above the test I just wrote. It isn't any more difficult.
This assumes a lot of things around the code that you're executing. First, you've already setup a test and it's already isolated enough. With a powerful repl + idioms, you don't need to do that, as you can execute parts of a function just to introspect that part, kind of like a debugger but works anywhere automatically.
In the end, I'm not gonna try to convince you to try something if you don't want to try it. But if you're anything like me, finding more productive ways of working is always interesting, even if they end up not being as productive as we first thought. With that in mind, since you seem to not have super much experience with a powerful repl, if you try it I'm sure you'll find what I say to be helping you be a better programmer.
>you still make your changes in your favorite editor and code is still tracked in version control.
Version control does not track which sequence of code snippets you have (re)-evaluated to get to your current repl state. I'm fully aware of how editor integration with a Lisp repl works in Emacs and (to a lesser extent) Vim.
>have dabbled...In the end, I'm not gonna try to convince you to try something...seem not to have super much experience with a powerful repl...etc.
As with most Lisp advocates, you seem unable to a accept that I have tried it and didn't like it. Please stop throwing shade.
> This assumes a lot of things around the code that you're executing. First, you've already setup a test and it's already isolated enough
A test in Go is just a function, so no set up is required. A test is more isolated than an expression evaluated in a repl.
It seems to me that you don't have much experience of writing tests in a modern development environment, and this is why manually recompiling parts of your codebase using Vim hotkeys strikes you as a good idea :)
Also you kinda don't need a repl as much with go (coming from a python background and constantly repl-dev-ing), especially with an IDE. Everything is so clear and type-safe there is little divide between the architecture in my mind and the code's behavior.
It's not that you don't need a repl. It's that you don't really get the many benefits other repl-heavy languages have, like Smalltalk and the many different lisps. You got a lot of implicit state and other non-ergonimic constructs in the language that doesn't lend itself to live in a repl for development. Also I expanded a bit more on why Golang doesn't fit for repls in general here: https://news.ycombinator.com/item?id=23053343
There's a whole section in the article about that. C would be a pretty obviously terrible choice so I'm not sure why you would consider that.
Java would be ok but Go is much simpler to get started with and to deploy. In general it is more lightweight and easier to use (unless you need generics, though Java doesn't really do those right either).
One nice thing about Go and C vs Java, is that a program can be (statically) compiled into a single, stand-alone executable that have no external dependencies.
